Launching Chromium on startup with systemd
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
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
boot systemd opensuse
add a comment |Â
up vote
1
down vote
favorite
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
boot systemd opensuse
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
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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
boot systemd opensuse
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
boot systemd opensuse
boot systemd opensuse
asked Aug 14 '17 at 4:02
Hartun
184
184
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
add a comment |Â
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
1
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
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
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
@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
@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
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
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
add a comment |Â
3 Answers
3
active
oldest
votes
up vote
1
down vote
accepted
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
- Lennart Poettering et al. (2016). systemd.special. systemd manual pages. Freedesktop.org.
- Martin Pitt (2016-07-25). units: add graphical-session.target user unit. systemd bug #3678.
- Martin Pitt (2016-09-29). graphical-session.target. systemd.conf. Youtube.
- Ian Lane (2017-07-30). systemd in GNOME user sessions. GUADEC 2017. Youtube.
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
Aug 15 '17 at 21:05
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
0
down vote
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
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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
- Lennart Poettering et al. (2016). systemd.special. systemd manual pages. Freedesktop.org.
- Martin Pitt (2016-07-25). units: add graphical-session.target user unit. systemd bug #3678.
- Martin Pitt (2016-09-29). graphical-session.target. systemd.conf. Youtube.
- Ian Lane (2017-07-30). systemd in GNOME user sessions. GUADEC 2017. Youtube.
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
Aug 15 '17 at 21:05
add a comment |Â
up vote
1
down vote
accepted
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
- Lennart Poettering et al. (2016). systemd.special. systemd manual pages. Freedesktop.org.
- Martin Pitt (2016-07-25). units: add graphical-session.target user unit. systemd bug #3678.
- Martin Pitt (2016-09-29). graphical-session.target. systemd.conf. Youtube.
- Ian Lane (2017-07-30). systemd in GNOME user sessions. GUADEC 2017. Youtube.
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
Aug 15 '17 at 21:05
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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
- Lennart Poettering et al. (2016). systemd.special. systemd manual pages. Freedesktop.org.
- Martin Pitt (2016-07-25). units: add graphical-session.target user unit. systemd bug #3678.
- Martin Pitt (2016-09-29). graphical-session.target. systemd.conf. Youtube.
- Ian Lane (2017-07-30). systemd in GNOME user sessions. GUADEC 2017. Youtube.
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
- Lennart Poettering et al. (2016). systemd.special. systemd manual pages. Freedesktop.org.
- Martin Pitt (2016-07-25). units: add graphical-session.target user unit. systemd bug #3678.
- Martin Pitt (2016-09-29). graphical-session.target. systemd.conf. Youtube.
- Ian Lane (2017-07-30). systemd in GNOME user sessions. GUADEC 2017. Youtube.
edited Aug 15 '17 at 5:19
answered Aug 14 '17 at 6:26
JdeBP
29.4k460136
29.4k460136
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
Aug 15 '17 at 21:05
add a comment |Â
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
Aug 15 '17 at 21:05
What is the recommended way to run a proccess on startup?
â Hartun
Aug 14 '17 at 19:06
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
Aug 15 '17 at 21:05
@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
Aug 15 '17 at 21:05
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
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.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Aug 14 '17 at 15:01
Mark Stosberg
3,5941023
3,5941023
add a comment |Â
add a comment |Â
up vote
0
down vote
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
add a comment |Â
up vote
0
down vote
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
add a comment |Â
up vote
0
down vote
up vote
0
down vote
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
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
answered Aug 15 at 7:43
Hemang Chawla
11
11
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f385964%2flaunching-chromium-on-startup-with-systemd%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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