8

Task: Start Chromium on startup on openSUSE machine

Problem: I think the problem is that I want to start a GUI program

So far:

Mon Aug 14; 06:45:00; marton;/etc/systemd ;  $  
Mon Aug 14; 06:45:00; marton;/etc/systemd ;  $  ls -l
total 24
-rw-r--r-- 1 root root  529 Mar 15 07:20 bootchart.conf
-rw-rw-r-- 1 root root  138 Aug 14 06:34 chorm_start.service
-rw-r--r-- 1 root root  768 Mar 15 07:20 journald.conf
-rw-r--r-- 1 root root  709 Mar 15 07:20 logind.conf
drwxr-xr-x 1 root root  772 Aug 14 05:16 system
-rw-r--r-- 1 root root 1196 Mar 15 07:20 system.conf
drwxr-xr-x 1 root root    0 Mar 15 07:20 user
-rw-r--r-- 1 root root  992 Mar 15 07:20 user.conf
Mon Aug 14; 06:45:00; marton;/etc/systemd ;  $  sudo chmod 664 chorm_start.service 
root's password:
Mon Aug 14; 06:45:19; marton;/etc/systemd ;  $  ls -l
total 24
-rw-r--r-- 1 root root  529 Mar 15 07:20 bootchart.conf
-rw-rw-r-- 1 root root  138 Aug 14 06:34 chorm_start.service
-rw-r--r-- 1 root root  768 Mar 15 07:20 journald.conf
-rw-r--r-- 1 root root  709 Mar 15 07:20 logind.conf
drwxr-xr-x 1 root root  772 Aug 14 05:16 system
-rw-r--r-- 1 root root 1196 Mar 15 07:20 system.conf
drwxr-xr-x 1 root root    0 Mar 15 07:20 user
-rw-r--r-- 1 root root  992 Mar 15 07:20 user.conf
Mon Aug 14; 06:45:20; marton;/etc/systemd ;  $  cat chorm_start.service                      
[Unit]                                                                                       
Description="Starting chromium on startup"                                                   

[Service]                                                                                    
ExecStart=/usr/lib64/chromium/chromium                                                       

[Install]                                                                                    
WantedBy=multi-user.target                                                                   
Mon Aug 14; 06:45:38; marton;/etc/systemd ;  $  sudo systemctl status chorm_start
chorm_start.service - "Starting chromium on startup"                                         
   Loaded: loaded (/etc/systemd/chorm_start.service; enabled)                                
   Active: failed (Result: exit-code) since Mon 2017-08-14 06:38:44 EEST; 7min ago           
  Process: 853 ExecStart=/usr/lib64/chromium/chromium (code=exited, status=1/FAILURE)
 Main PID: 853 (code=exited, status=1/FAILURE)

Aug 14 06:38:47 date chromium[853]: Unable to init server: Could not connect: Connection refused
Aug 14 06:38:47 date chromium[853]: [853:853:0814/063844.727638:ERROR:browser_main_loop.cc(279)] Gtk: cannot open display:
Mon Aug 14; 06:46:35; marton;/etc/systemd ;  $  

Question: What am I doing wrong and how to solve the problem

5
  • 1
    You'll have to provide the screen for chrome to connect to. Do you want it to pop-up on your (automatically opened) desktop? On some virtual X display? – Anthon Aug 14 '17 at 5:16
  • Why does it need to be started by systemd? This just seems to propogate the systemd madness. – symcbean Aug 14 '17 at 13:35
  • @Anthon I want it to pop on my desktop(cntrl + alt + F7) – Hartun Aug 14 '17 at 19:03
  • @symcbean well, I heard crontab is not a good idea, there is rc.local or something like that which is hard to pull off because the internet is flooded with Debian solutions ONLY and systemd looks easy and universal for every distro – Hartun Aug 14 '17 at 19:05
  • 2
    rc.local is not the place to start up interactive programs (except for possible [x|k|g]dm). While systemd provides an interface for everything that still makes it the wrong place to start the program. The browser is dependent on a user session and you need to ensure the latter is in place - the easiest way to do that is by starting it from the session. – symcbean Aug 15 '17 at 8:26
10

And now, the systemd answer.

Since you did ask how to do it with systemd. ☺

This is how the systemd people have been telling people to do this.

You are putting the service unit file in entirely the wrong directory. It should not go in /etc/systemd. It should not even go in /etc/systemd/system. It should go in ~marton/.config/systemd/user.

This is because a graphical program that you want to run under the aegis of your own account is a per-user service not a system service. (You are currently invoking a WWW browser as the superuser. That is a very bad idea. Stop that now!) You could configure it for all users in the /etc/systemd/user directory, but it is probable that not all users on your machine need to start Chromium as a service. So configure it just for your user account, specifically.

As it is a per-user service, you should manipulate it with the --user option to systemctl, sans sudo. For example:

systemctl --user status chrome.service

That goes for enabling and disabling it, too.

As a per-user service unit, it should be WantedBy=default.target, because there is no multi-user.target for per-user services. (Although I suspect it should actually be WantedBy=your-desktop-session.target, which will be something like gnome-session.target depending from what desktop your are using. What the systemd people have been saying is not wondrously clear on this point.)

And one part of the systemd people's bodge to make per-user services look like per-login-session services is the whole graphical-session mechanism, which your service unit must incorporate with the setting:

[Unit]
PartOf=graphical-session.target

What else you have to do depends from how far OpenSuSE has got with the whole graphical-session bodge, which systemd people started pushing in 2016. Ubuntu and Debian provide a whole mess of behind the scenes shell scripting in GUI login session startup and shutdown that bodges both the starting/stopping of graphical-session.target and injecting the DISPLAY environment variable. If your OpenSuSE does not yet have this, you might have to fill in that part.

Further reading

3
  • What is the recommended way to run a proccess on startup? – Hartun Aug 14 '17 at 19:06
  • @Hartun Systemd is the way to run a process on startup these days. But you don't want to run a process on startup, you want to run a process on login, which is a completely different thing. The recommended way to start a process on GUI login to add it to your desktop environment's autostart applications. – Gilles 'SO- stop being evil' Aug 15 '17 at 21:05
  • 1
    Until graphical-session.target arrives for Debian, have a look here. – Suuuehgi May 17 '19 at 18:51
3

In short (additionally to JdeBP):

  1. Never ever use root if not absolutely needed. Least of all for the browser since most of the myriad bugs in them would result in direct root access to the attacker.

  2. Put your systemd files in ~/.config/systemd/user

  3. Enable: E.g. systemctl --user enable firefox

~/.config/systemd/user/firefox.service:

[Unit]
Description=Start Firefox
PartOf=graphical-session.target

[Service]
ExecStart=/usr/bin/firefox
Type=oneshot

[Install]
WantedBy=graphical-session.target

This should start Firefox at boot.


If graphical-session.target is not the right for you (since there is something other managed by the login manager, your display manager or Google knows what) have a look at systemctl --user status *.target what other there might be.


If graphical-session.target is not active after graphical login (you might have an old or stable system), you can manually start it by adding the following to your ~/.xsessionrc:

systemctl --no-block --user start graphical-session.target
1

I tried this myself, and like you found that systemd is the wrong tool for the job when it comes to starting graphical desktop apps. An easy approach is to use the "autostart apps" feature of your preferred desktop environment.

The difference is that systemd does not have easy access to the DISPLAY environment variable, while the "auto start apps" approach will.

-1

This works for me. The key is to add the User in the Service, along with initiating the DISPLAY in the Environment .

[Unit]
Description=launch chromium

[Service]
User=<user>
Environment=DISPLAY=:0
ExecStart=/usr/bin/chromium-browser

[Install]
WantedBy=user@.service
1
  • 1
    The answer implies that this snippet and hence the browser is being run as root what JdeBP already said to be a horrible idea. Instead, run it via systemctl --user and kick out the User= and Environment=, change WantedBy= to graphical-session.target. – Suuuehgi May 17 '19 at 20:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.