[systemd-devel] Create a new logind session from a systemd --user unit

Lennart Poettering lennart at poettering.net
Mon Jul 29 16:02:10 PDT 2013

On Sat, 27.07.13 21:47, Abdó Roig-Maranges (abdo.roig at gmail.com) wrote:

> Hello,
> I'm happily using systemd 204 user instance to handle my desktop (xorg, awesome
> wm, mpd, etc.) in Arch. I started experimenting with systemd 206 trying to adapt
> my setup to the changes in cgroups, slices, and all that.
> In 206, systemd user session is started automatically by pam_systemd when I
> login to a tty. Then, I want to manually launch my window manager, in a new
> logind session for my user, on a different tty.

This is not supported by logind. You cannot allocate sessions from other
sessions, only from the system daemon. This is because we try to keep the
various session definitions in sync, for example the audit session which
is nowadays "sealed" off by the kernel.

Either use a display manager or simply "update" your existing session's
tty to graphical temporarily, rather then placing things on a new
tty. (Note that the Fedora startx script does this implicitly this way)

Note that "systemd --user" is WIP (which is why you find very little
documentation about it from us, except the most basic reference in the
man pages). It was never supposed to be run from login sessions (it's
not called "systemd --session" but "systemd --user" for a reason) except
for debugging purposes. Recent systemd versions make this a bit harder
than before since for security reasons normal user sessions do not get
write access to their cgroup tree anymore, only user at .service gets.

Now, user at .service is not complete yet. To be fully useful we need some
support from X11, so that it can connect to the X11 display via
$XDG_RUNTIME_DIR/display, rather than relying on $DISPLAY. Also, D-Bus
needs to look for the bus socket in $XDG_RUNTIME_DIR too.

We are working on this bit by bit. If you want this to go faster, then
please work with us, and write patches for libX11 and D-Bus.

If you need an quick solution immediately I suggest you simply chown the
sessions cgroup tree to your own user. That's a hack, and requires
privileges, but is what I do for testing purposes.


Lennart Poettering - Red Hat, Inc.

More information about the systemd-devel mailing list