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 ali...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel