Systemd has many amazing features, one of which is the ability to track programs using cgroups (by running {{ic|systemctl status}}). While awesome for a pid 1 process to do, it is also extremely useful for users, and having it set up and initialize user programs, all the while tracking what is in each cgroup is even more amazing.

Systemd has many amazing features, one of which is the ability to track programs using cgroups (by running {{ic|systemctl status}}). While awesome for a pid 1 process to do, it is also extremely useful for users, and having it set up and initialize user programs, all the while tracking what is in each cgroup is even more amazing.

−

I began using [http://blog.gtmanfred.com/?p=26 gtmanfred's guide] to setting this up. I rewrote it partially to be of more help, and partially to help get this into my head even more.

+

I began using [http://blog.gtmanfred.com/?p=26 gtmanfred's guide] to set this up. I rewrote it partially to be of more help, and partially to help get this into my head even more.

All of your systemd user units will go to $HOME/.config/systemd/user. These units take precedence over units in other systemd unit directories.

All of your systemd user units will go to $HOME/.config/systemd/user. These units take precedence over units in other systemd unit directories.

You will need to patch systemd to do this, so either using systemd-git from after [http://cgit.freedesktop.org/systemd/systemd/commit/?id=067d851d30386c553e3a84f59d81d003ff638b91 commit 067d851d] or patch it into systemd with the [[ABS]].

+

You will need to patch systemd to do this, so either using systemd-git from after [http://cgit.freedesktop.org/systemd/systemd/commit/?id=067d851d30386c553e3a84f59d81d003ff638b91 commit 067d851d] or patch it into systemd with the [[ABS]]. After 197, it should be in the mainline systemd.

Last but not least, add this line to /etc/pam.d/login or /etc/pam.d/systemd-auth (whichever exists):

Last but not least, add this line to /etc/pam.d/login or /etc/pam.d/systemd-auth (whichever exists):

Revision as of 05:51, 24 December 2012

systemd offers users the ability to run an instance of systemd to manage their session and services. This allows users to start, stop, enable, and disable units found within certain directories when systemd is run by the user. This is convenient for daemons and other services that are commonly run as a user other than root or a special user, such as mpd.

Contents

Setup

Using systemd --user To Manage Your Session

Systemd has many amazing features, one of which is the ability to track programs using cgroups (by running systemctl status). While awesome for a pid 1 process to do, it is also extremely useful for users, and having it set up and initialize user programs, all the while tracking what is in each cgroup is even more amazing.

I began using gtmanfred's guide to set this up. I rewrote it partially to be of more help, and partially to help get this into my head even more.

All of your systemd user units will go to $HOME/.config/systemd/user. These units take precedence over units in other systemd unit directories.

Note the [Install] section includes a 'WantedBy' part. When using systemctl --user enable it will link this as $HOME/.config/systemd/user/i3wm.target.wants/i3.service, allowing it to be started at login. I would recommend enabling this service, not linking it manually.

You can fill your user unit directory with a plethora of services, I currently have ones for mpd, gpg-agent, offlineimap, parcellite, pulse, tmux, urxvtd, xbindkeys and xmodmap to name a few.

Doing this will not allow you to run systemd --user, though. If you installed user-session-units as listed above, then you must copy user-session@.service to your user unit directory and use systemctl --user enable user-session@yourloginname.service (replace the obvious). Next, edit the user-session@.service (not the user-session@yourloginname.service) and edit this line:

You will need to patch systemd to do this, so either using systemd-git from after commit 067d851d or patch it into systemd with the ABS. After 197, it should be in the mainline systemd.

Last but not least, add this line to /etc/pam.d/login or /etc/pam.d/systemd-auth (whichever exists):

session required pam_systemd.so

Now add /usr/lib/systemd/systemd --user to your shell's $HOME/.*profile file and you are ready to go! (This takes a lot of tweaking, so when I say that, I mean that you are ready to debug and find spelling mistakes.)

One of the most important things you can add to the service files you will be writing is the use of Before= and After= in the [Unit] section. These two parts will determine the order things are started. Say you have a graphical application you want to start on boot, you would put `After=xorg.target' into your unit. Say you start ncmpcpp, which requires mpd to start, you can put `After=mpd.service' into your ncmpcpp unit. You will eventually figure out exactly how this needs to go either from experience or from reading the systemd manual pages. I would recommend starting with systemd.unit(5).

Once all of this is up and running, you can type systemctl --user status i3.service (or whatever your window manager or desktop environment is called) and see something like this:

Note: For future fun, remember that you can write <unit>@.services too, and in that service %i will expand to the text between the @ and the .service part, so if I wanted to have multiple instances of a window manager, for example on different displays, I could set the DISPLAY=%i and enable i3@:0.service or even i3@123.123.123.123:5.service if that tickled my fancy.

startx

Users should first set up systemd-logind to manage their session. If systemd is running as the system init daemon, then this is already happening.

Next, the user must launch systemd by putting the following in their ~/.xinitrcbefore the exec line:

systemd --user &

After starting X, the user can check whether their session is now being managed by systemd-logind with the following command:

$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active

If this command prints Active=yes, then the user is now using systemd-logind to manage their session. The user should remove any instances of ck-launch-session or dbus-launch from their ~/.xinitrc, as those commands are unneeded.

Display Managers

All of the major display managers are now using systemd-logind by default, so the loginctl command from the previous section should work as stated. A user simply has to add systemd --user as a program to be started by their desktop environment.

User Services

Users may now interact with units located in the following directories just as they would with system services (ordered by ascending precedence):

/usr/lib/systemd/user/

/etc/systemd/user/

~/.config/systemd/user/

To control the systemd instance, the user must use the command systemctl --user.

Installed by packages

A unit installed by a package that is meant to be run by a systemd user instance should install the unit to /usr/lib/systemd/user/. The system adminstration can then modify the unit by copying it to /etc/systemd/user/. A user can then modify the unit by copying it to ~/.config/systemd/user/.