Difference between revisions of "Talk:Systemd/User"

From ArchWiki
Jump to: navigation, search
(Setting Environment variables without autologin/user-session@.service)
(Setting up DISPLAY variable for systemd-user unit under Wayland session: re)
 
(32 intermediate revisions by 11 users not shown)
Line 5: Line 5:
  
 
::Not really. I'm not using auto-login and I'm not using any DE or login manager. It was a bug I ''believe'' on older versions on systemd. Since 198 it's not longer necessary. I still get that error on the start but it actually works without hassle. --[[User:Pabloxcl|Pabloxcl]] ([[User talk:Pabloxcl|talk]]) 16:21, 7 April 2013 (UTC)
 
::Not really. I'm not using auto-login and I'm not using any DE or login manager. It was a bug I ''believe'' on older versions on systemd. Since 198 it's not longer necessary. I still get that error on the start but it actually works without hassle. --[[User:Pabloxcl|Pabloxcl]] ([[User talk:Pabloxcl|talk]]) 16:21, 7 April 2013 (UTC)
 +
 +
== Increasing priority of user services ==
 +
 +
How can I increase priority for user services? When I try to use {{ic|1=CPUShares=2048}}, I get {{ic|Failed to create cgroup cpu:/user/1000.user/2.session/systemd-536/xorg.service: Permission denied}}, when I try to use {{ic|1=Nice=-15}}, I get {{ic|Failed at step NICE spawning /usr/bin/xorg-launch-helper: Permission denied}}.
 +
 +
== Starting services using a display manager ==
 +
 +
I had a hard time trying to use {{ic|systemd --user}} with a display manager. I use Slim, so I just put {{ic|systemd --user &}} in my {{ic|~/.xinitrc}} just before starting my WM (Awesome). Systemd started but nothing else happened. In fact I had to create a {{ic|default.target}} file in {{ic|~/.config/systemd/user/}} containing only
 +
[Unit]
 +
AllowIsolate=yes
 +
and then enable services provided that each file contains
 +
[Install]
 +
WantedBy=default.target
 +
Then all went well, {{ic|systemd --user}} launch a dbus user session and all enabled service.
 +
 +
I think the important part is the {{ic|default.target}} file, which is documented in [[Systemd/User#Using /usr/lib/systemd/systemd --user To Manage Your Session]] but not at all talked about in the previous sections. I'm not sure how to add this to the wiki, or even if my method is the right way to do it using a DM, So I prefer discuss this on this page. [[User:Ianux|Ianux]] ([[User talk:Ianux|talk]]) 17:57, 14 September 2013 (UTC)
 +
 +
== Passing DBUS_SESSION_BUS_ADDRESS to session ==
 +
 +
After setting variable in <tt>/etc/systemd/system/user@.service.d/dbus.conf</tt> it is present in systemd --user (and its services) environment, as can be verified by <tt>systemctl --user show-environment</tt>, but how is it exactly passed to session processes? [[User:Pmartycz|Pmartycz]] ([[User talk:Pmartycz|talk]]) 14:20, 4 July 2015 (UTC)
 +
 +
:It isn't, because {{ic|systemd --user}} runs outside the user session. The default {{ic|/etc/X11/xinit/xinitrc.d/30-dbus.sh}} starts another bus exclusively for the X session. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:43, 4 July 2015 (UTC)
 +
 +
::I thought the intent of this guide was to setup a single "user" bus shared by all user sessions (X, text, remote SSH logins) and by {{ic|systemd --user}}, wasn't it? [[User:Pmartycz|Pmartycz]] ([[User talk:Pmartycz|talk]]) 18:16, 4 July 2015 (UTC)
 +
 +
:::The first paragraph of [[Systemd/User#D-Bus]] explains the purpose. There are multiple different ways which will all "work" in certain cases. The current recommended way seems to be having multiple user buses, but in the future, as grawity indicated below, there will be only a single bus. If you want to see if the single bus aproach works for you, just {{ic|1=export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus}} from your shell startup file and make sure that {{ic|/etc/X11/xinit/xinitrc.d/30-dbus.sh}} is not run. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:48, 4 July 2015 (UTC)
 +
 +
::::Somehow it wasn't clear to me. Anyway, I think the best place for setting this variable would be somewhere in PAM. [[User:Pmartycz|Pmartycz]] ([[User talk:Pmartycz|talk]]) 21:02, 4 July 2015 (UTC)
 +
 +
:On a kdbus system, {{ic|pam_systemd}} would set it for you. --[[User:Grawity|grawity]] ([[User talk:Grawity|talk]]) 16:06, 4 July 2015 (UTC)
 +
 +
== Simplifying the Xorg and Systemd section ==
 +
 +
Why doesn't the [[Systemd/User#Xorg_and_systemd]] just use the startx wrapper program? I set up a service file like this and it seems to work just fine:
 +
 +
{{hc|~/.config/systemd/user/xorg.service|<nowiki>
 +
[Unit]
 +
Description=Xorg server
 +
 +
[Service]
 +
Type=simple
 +
SuccessExitStatus=0 1
 +
 +
ExecStart=/usr/bin/startx
 +
</nowiki>}}
 +
 +
This seems a lot simpler than the configuration described. Sorry if this is a dumb question!
 +
[[User:Siddharthist|Siddharthist]] ([[User talk:Siddharthist|talk]]) 02:49, 9 May 2016 (UTC)
 +
 +
== Variable expansion implied by Service example ==
 +
 +
The example under the [[Systemd/User#Service example|Service example]] section implies that variable expansion will work in a systemd unit, however, from my understanding and experience this is not the case and so the {{ic|PATH}} variable would not be extended as it might seem. [[User:Flungo|Flungo]] ([[User talk:Flungo|talk]]) 19:49, 28 August 2016 (UTC)
 +
 +
:Expansion of variables works in systemd units, see {{man|5|systemd.service|COMMAND_LINES}}. It's just that {{ic|$PATH}} in the systemd unit is not the same as {{ic|$PATH}} in the shell, most notably the value does not propagate automatically from the shell into systemd. This is what [[Systemd/User#Environment_variables]] is all about. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:49, 12 September 2016 (UTC)
 +
 +
::The referenced example implied that variable expansion worked within Environment lines. It only works within Command lines, per the linked manpage. And even then it only works as a bare word, like {{ic|/bin/true $FOO bar}}. To use within a word it must be wrapped in curlies, like {{ic|1=PATH=${FOO}:/bin}}. I updated the example to remove the variable reference. [[User:Sj26|Sj26]] ([[User talk:Sj26|talk]]) 15:51, 11 March 2017 (UTC)
 +
 +
== user@userid.service.d drop-ins ==
 +
 +
Since I'm researching ways to pass environment variables to {{ic|systemd --user}} I found out you can actually create a drop-in directory for a specific userid (eg {{ic|/etc/systemd/system/user@1000.service.d/}}. I thought about mentioning it in the page, but I am not sure it is good practice. What do you think? [[User:Farsil|Farsil]] ([[User talk:Farsil|talk]]) 22:15, 6 December 2016 (UTC)
 +
 +
== Setting up DISPLAY variable for systemd-user unit under Wayland session ==
 +
 +
On Wayland session (notably Weston), the {{Ic|/etc/X11/xinit/xinitrc.d/50-systemd-user.sh}} is not parsed, so that systemd-user units don't aware of the {{Ic|DISPLAY}} environment variable.
 +
 +
User need to run {{Ic|systemctl --user import-environment DISPLAY WAYLAND_DISPLAY}} so that systemd user service can make use of the variable.
 +
 +
[[User:Alive4ever|Alive4ever]] ([[User talk:Alive4ever|talk]]) 13:14, 13 April 2017 (UTC)
 +
 +
:Why do you need {{ic|DISPLAY}} in Wayland? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:00, 13 April 2017 (UTC)
 +
 +
::Because most GUI applications, such as web browsers, don't have complete Wayland support and therefore needs {{Ic|DISPLAY}} environment variable to run under Xwayland.
 +
::Real use case is {{Ic|gpg-agent}} systemd user service need to know {{Ic|DISPLAY}} to invoke proper {{Ic|pinentry}} gui to ask for passphrase.
 +
::{{Ic|ssh-agent}} is also another case, where it needs to know {{Ic|DISPLAY}} to invoke {{Ic|ssh-askpass}}.
 +
::[[User:Alive4ever|Alive4ever]] ([[User talk:Alive4ever|talk]]) 13:14, 13 April 2017 (UTC)
 +
 +
:::I'd say that counts as a "non-standard way of starting X", in which case the section implies that you should run the {{ic|/etc/X11/xinit/xinitrc.d/50-systemd-user.sh}} script manually or incorporate it into your way of starting X. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:13, 13 April 2017 (UTC)

Latest revision as of 14:14, 13 April 2017

Setting Environment variables without autologin/user-session@.service

If you're not using auto-login, specifically the user-session@service, the environment variable DBUS_SESSION_BUS_ADDRESS needs to exported to something like export DBUS_SESSION_BUS_ADDRESS=/run/user/$(id -u)/dbus/user_bus_socket before systemd --user. Otherwise, an error shows up in journalctl : "systemd[3975]: Failed to open private bus connection: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11." Are there any other environment variables that need to be added to that section? Feynman (talk) 23:57, 5 February 2013 (UTC)

Not really. I'm not using auto-login and I'm not using any DE or login manager. It was a bug I believe on older versions on systemd. Since 198 it's not longer necessary. I still get that error on the start but it actually works without hassle. --Pabloxcl (talk) 16:21, 7 April 2013 (UTC)

Increasing priority of user services

How can I increase priority for user services? When I try to use CPUShares=2048, I get Failed to create cgroup cpu:/user/1000.user/2.session/systemd-536/xorg.service: Permission denied, when I try to use Nice=-15, I get Failed at step NICE spawning /usr/bin/xorg-launch-helper: Permission denied.

Starting services using a display manager

I had a hard time trying to use systemd --user with a display manager. I use Slim, so I just put systemd --user & in my ~/.xinitrc just before starting my WM (Awesome). Systemd started but nothing else happened. In fact I had to create a default.target file in ~/.config/systemd/user/ containing only

[Unit]
AllowIsolate=yes

and then enable services provided that each file contains

[Install]
WantedBy=default.target

Then all went well, systemd --user launch a dbus user session and all enabled service.

I think the important part is the default.target file, which is documented in Systemd/User#Using /usr/lib/systemd/systemd --user To Manage Your Session but not at all talked about in the previous sections. I'm not sure how to add this to the wiki, or even if my method is the right way to do it using a DM, So I prefer discuss this on this page. Ianux (talk) 17:57, 14 September 2013 (UTC)

Passing DBUS_SESSION_BUS_ADDRESS to session

After setting variable in /etc/systemd/system/user@.service.d/dbus.conf it is present in systemd --user (and its services) environment, as can be verified by systemctl --user show-environment, but how is it exactly passed to session processes? Pmartycz (talk) 14:20, 4 July 2015 (UTC)

It isn't, because systemd --user runs outside the user session. The default /etc/X11/xinit/xinitrc.d/30-dbus.sh starts another bus exclusively for the X session. -- Lahwaacz (talk) 14:43, 4 July 2015 (UTC)
I thought the intent of this guide was to setup a single "user" bus shared by all user sessions (X, text, remote SSH logins) and by systemd --user, wasn't it? Pmartycz (talk) 18:16, 4 July 2015 (UTC)
The first paragraph of Systemd/User#D-Bus explains the purpose. There are multiple different ways which will all "work" in certain cases. The current recommended way seems to be having multiple user buses, but in the future, as grawity indicated below, there will be only a single bus. If you want to see if the single bus aproach works for you, just export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus from your shell startup file and make sure that /etc/X11/xinit/xinitrc.d/30-dbus.sh is not run. -- Lahwaacz (talk) 18:48, 4 July 2015 (UTC)
Somehow it wasn't clear to me. Anyway, I think the best place for setting this variable would be somewhere in PAM. Pmartycz (talk) 21:02, 4 July 2015 (UTC)
On a kdbus system, pam_systemd would set it for you. --grawity (talk) 16:06, 4 July 2015 (UTC)

Simplifying the Xorg and Systemd section

Why doesn't the Systemd/User#Xorg_and_systemd just use the startx wrapper program? I set up a service file like this and it seems to work just fine:

~/.config/systemd/user/xorg.service
[Unit]
Description=Xorg server

[Service]
Type=simple
SuccessExitStatus=0 1

ExecStart=/usr/bin/startx

This seems a lot simpler than the configuration described. Sorry if this is a dumb question! Siddharthist (talk) 02:49, 9 May 2016 (UTC)

Variable expansion implied by Service example

The example under the Service example section implies that variable expansion will work in a systemd unit, however, from my understanding and experience this is not the case and so the PATH variable would not be extended as it might seem. Flungo (talk) 19:49, 28 August 2016 (UTC)

Expansion of variables works in systemd units, see systemd.service(5). It's just that $PATH in the systemd unit is not the same as $PATH in the shell, most notably the value does not propagate automatically from the shell into systemd. This is what Systemd/User#Environment_variables is all about. -- Lahwaacz (talk) 13:49, 12 September 2016 (UTC)
The referenced example implied that variable expansion worked within Environment lines. It only works within Command lines, per the linked manpage. And even then it only works as a bare word, like /bin/true $FOO bar. To use within a word it must be wrapped in curlies, like PATH=${FOO}:/bin. I updated the example to remove the variable reference. Sj26 (talk) 15:51, 11 March 2017 (UTC)

user@userid.service.d drop-ins

Since I'm researching ways to pass environment variables to systemd --user I found out you can actually create a drop-in directory for a specific userid (eg /etc/systemd/system/user@1000.service.d/. I thought about mentioning it in the page, but I am not sure it is good practice. What do you think? Farsil (talk) 22:15, 6 December 2016 (UTC)

Setting up DISPLAY variable for systemd-user unit under Wayland session

On Wayland session (notably Weston), the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh is not parsed, so that systemd-user units don't aware of the DISPLAY environment variable.

User need to run systemctl --user import-environment DISPLAY WAYLAND_DISPLAY so that systemd user service can make use of the variable.

Alive4ever (talk) 13:14, 13 April 2017 (UTC)

Why do you need DISPLAY in Wayland? -- Lahwaacz (talk) 09:00, 13 April 2017 (UTC)
Because most GUI applications, such as web browsers, don't have complete Wayland support and therefore needs DISPLAY environment variable to run under Xwayland.
Real use case is gpg-agent systemd user service need to know DISPLAY to invoke proper pinentry gui to ask for passphrase.
ssh-agent is also another case, where it needs to know DISPLAY to invoke ssh-askpass.
Alive4ever (talk) 13:14, 13 April 2017 (UTC)
I'd say that counts as a "non-standard way of starting X", in which case the section implies that you should run the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh script manually or incorporate it into your way of starting X. -- Lahwaacz (talk) 14:13, 13 April 2017 (UTC)