On Wed, Oct 9, 2013 at 3:59 PM, Colin Walters <walt...@verbum.org> wrote: > Your patch seems to be at odds with the commit message; since > DBUS_SESSION_BUS_ADDRESS won't be set for the user bus, we won't > attempt a connection, right?
In the current code? Yes, but then it won't attempt to set up the *private* socket either ($XDG_RUNTIME_DIR/systemd/private), because bus_init() is skipped completely. However, when bus_init(m, false) is called, then it won't try the system or api bus, but will set up the private socket anyway. > What you're really trying to fix I assume is the warning systemd outputs > when it currently spawns user@? No – what I'm trying to fix is systemd's behavior in the (admittedly very unlikely) case when it's started without DBUS_SESSION_BUS_ADDRESS in environment (for example, which I had to do last week when helping someone on IRC fix their user@.service). Specifically, systemd --user should always be controllable through the $XDG_RUNTIME_DIR/systemd/private socket – even if said DBus environment variable is missing or if it cannot connect to DBus for some other reason. (On the second thought, I should've probably also adjusted bus_init() to move the call to bus_init_private() a little higher.) -- Mantas Mikulėnas <graw...@gmail.com> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
