[systemd-devel] user units and system units behavior

[Alison Chaiken]

Thanks very much, Ivan, for the detailed explanation.

I asked:
>> Question: What does the error message 'Process
>> org.freedesktop.systemd1 exited with status 1' mean?

Ivan:
> this is a sign of that the systemd user instance (`systemd --user`)
> isn't running.  More specifically, the systemd user instance wasn't running, so its bus
> name hadn't been taken, so the dbus1 server tried to do the "bus
> activation", but the dbus1 service file for systemd (not to be confused
> with systemd's unit files) contains Exec=/bin/false (as to prevent bus
> activation), so that activation had failed.

Why shouldn't the user be able to activate the systemd user instance?
 Should they start services in the /user unit directories with
'systemctl --session' then?    In the spirit of 'systemctl cat' and
'systemctl edit' commands that find the applicable unit even when the
invoker doesn't know the complete path, I would hope that non-SUID
users could type 'systemctl start foo.service' and it would "just
work".

Is 'systemctl --user' completely broken then?   If so, shouldn't we
remove it from the documentation?

'ps | grep dbus' does in fact show a "--session" bus on Fedora 21 and
GNOME, but I guess there is no direct 'plumbing' way to request it to
start units.   Instead the 'porcelain' GNOME method of configured
services calling each other is required.

Ivan:
> This is the current out-of-the-box situation. The problem lies in that
> there is currently no single "user bus". There is a number of session
> busses, launched by a scriptlet in /etc/X11/xinitrc.d for each X11
> session separately.

I see that for my fully updated, stock (except for freshly compiled
systemd) Fedora 21 GNOME installation that there is no
/etc/X11/xinitrc.d directory.   I take it that means that is no way
for users to start services without suid.    Services can only be
started by root, and only system services, as root's search path for
units does not include user units.

I read Simon McVittie's previous posting on related topics.   He says in part:

http://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html

>>>systemd-logind implements those semantics, and also runs a `systemd --user`
>>>for the lifetime of the user-session.    . . .
>>>In graphical sessions, vaguely modern Unix OSs typically know how to
>>>start up a dbus-daemon during the creation of a graphical session (e.g.
>>>in Debian and derivatives it's started by /etc/X11/Xsession.d, and
>>>Fedora derivatives have a similar setup under a different name). If they
>>>don't, modern desktop environments also know how to start a dbus-daemon
>>>if they need one (e.g. gnome-session does this for GNOME), and if *that*
>>>doesn't start one (the "I use Firefox under fvwm" use-case), we have a
>>>slightly shaky but functional "autolaunch" mechanism based on X11
>>>properties.

I suppose, Ivan, that your reference is to these autolaunch mechanisms
when you mentioned /etc/X11/xinitrc.d/.   But shouldn't gnome-session
be starting the user bus already?    gnome-session is running on the
stock Fedora 21, but 'ps -ppid' shows that it has parented no D-Bus
daemons.   I suppose that the takeaway then is that the gnome-session
in Fedora 21 is not ready for systemd 218.

> And this all is going to change when kdbus becomes finally there.

My original intention was to test 3.19 with kdbus and systemd 218 in a
Qemu, but so far I'm stumped by the initramfs creation for Fedora.
That's a different topic, though!

-- Alison

-- 
Alison Chaiken                           alison at she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals.  -- Don Norman