Talk:Systemd/User

From ArchWiki
Jump to: navigation, search

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)

KillUserProcesses Default to Yes With systemd 230

Perhaps somewhat controversially, as of version 230, systemd now defaults to KillUserProcesses=yes. See the news update for details. (I'll try to update that bit of the article later, if I don't forget.) - AfroThundr3007730 (talk) 15:57, 31 May 2016 (UTC)

As pointed out by Rdeckard in [1], there is nothing new for Arch.[2] -- Lahwaacz (talk) 16:05, 31 May 2016 (UTC)
Ah, very well then. No need to bother users with the little details. :) AfroThundr3007730 (talk) 16:29, 31 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)

pam_environment

I have added this section to the wiki as I think it may help other users having the same problem, but I am not entirely sure it is formatted in the right way, as this is my first major edit. If you have any questions or doubts about the section feel free to comment here. Farsil (talk) 13:49, 6 December 2016 (UTC)

I understand the reason behind the edit of the section I wrote, and I agree with it. But I think the information about modifying pam.d is useful if you want to make your pam_env settings available to the systemd user instance, which is necessary if you change the XDG_*_HOME environment variables. Do you think it could have a place in the Systemd FAQ? Farsil (talk) 15:41, 6 December 2016 (UTC)
I'm not sure why you say that editing those file is needed. All environment variables I've defined in my .pam_environment are visible to the systemd --user instance on my system. Could you clarify? -- Alad (talk) 16:15, 6 December 2016 (UTC)
If you don't change the pam.d/systemd-user file to use pam_env.so, the changed environment variables are not reflected in systemctl --user show-environment. pam.d/systemd-user does not load pam_env.so by default in Arch Linux (and it shouldn't). Farsil (talk) 17:05, 6 December 2016 (UTC)
It does for me and I haven't changed related files in /etc/pam.d (checked in /proc/<pid>/environ and systemctl --user show-environment). Maybe a third person could check? -- Alad (talk) 17:16, 6 December 2016 (UTC)
I asked on #archlinux-wiki and User:fsckd had the same results as me. -- Alad (talk) 18:51, 6 December 2016 (UTC)
I see, maybe it's something strange in my configuration then. Farsil (talk) 19:00, 6 December 2016 (UTC)
E.g. system-auth, system-login and system-services load pam_env.so so it makes sense that the variables propagate to systemd --user, though I'm not sure how the inheritance works exactly. -- Lahwaacz (talk) 19:38, 6 December 2016 (UTC)
Since systemd 232-6, the systemd-user file loads pam_env.so for me as well. I can finally confirm that editing systemd-user is not needed anymore. Farsil (talk) 19:43, 10 December 2016 (UTC)
Indeed, so we can close this. -- Lahwaacz (talk) 19:55, 10 December 2016 (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)