[systemd-devel] user units and system units behavior

[Ivan Shapovalov]

On 2015-02-14 at 09:36 -0800, Alison Chaiken wrote:
> 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?

The `systemd --user` is meant to be automatically started at time of
first login of the user by means of logind. The dbus activation
mechanism is deliberately disabled here.

So, if it isn't already running (which is the case), then that's the
problem... You may try to check user@$UID.service (is it running?).

>  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".

There is no `--session` switch to systemctl, just `--system` and
`--user`.

> 
> 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.

Yes, the per-session bus is there, but it is not used at all for
communication with per-user systemd instance.

> 
> 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.

Then they're placed in some distro-specific path. Again, the session bus
does not have to do anything with systemd user instances.

There is:
- system-wide systemd instance (PID 1) and system-wide bus (dbus.socket
+dbus.service)
- per-session bus (launched by a shell script in /etc/X11/<whatever>.d,
or autolaunched as Simon described)
- per-user systemd instance (user@$UID.service)

There is no per-user bus and there is no per-session systemd instance.

Also, both system-wide and per-user systemd instances have their own
_private_ buses, which are used as a fallback transport by systemctl,
systemd-analyze and suchlike tools.

For system-wide systemd, "fallback" means "before dbus.service is
started", i. e. in emergency.target and suchlike.
For per-user systemd, "fallback" means *always*. Because there is no
per-user bus.
Convoluted? Hell yeah.

> 
> 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/.

No, mine /etc/X11/xinitrc.d is Simon's /etc/X11/Xsession.d and "similar
setups". It's apparently a distro-specific path.

> 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.

Again, there is no "user bus"... Fedora 21 seems to have GNOME 3.14,
which I'm happily running under Arch together with current systemd git
master.

So, I suppose, your `systemd --user` just fails to start somewhy, and
you are getting that cryptic error message because systemctl can't find
systemd on either of the buses.

Hope it makes things a bit more clear. And I hope I haven't
misunderstood anything in the first place.

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150214/d4ca2f47/attachment.sig>