On Tue, May 29, 2012 at 7:56 PM, Kok, Auke-jan H <auke-jan.h....@intel.com> wrote: > On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie <gm...@colin.guthr.ie> wrote: >> 'Twas brillig, and Kok, Auke-jan H at 27/05/12 08:05 did gyre and gimble: >>> $ cat /usr/lib/systemd/user/dbus.service >>> [Unit] >>> Description=D-Bus System Message Bus >>> Requires=dbus.socket >>> >>> [Service] >>> ExecStartPre=/usr/bin/dbus-uuidgen --ensure >>> ExecStartPre=-/bin/rm -f /var/run/messagebus.pid >>> ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork >>> --systemd-activation >>> ExecReload=/usr/bin/dbus-send --print-reply --session >>> --type=method_call --dest=org.freedesktop.DBus / >>> org.freedesktop.DBus.ReloadConfig >>> OOMScoreAdjust=-900 >> >> >> Just a random observation from an uneducated user... but does the two >> ExecStartPre's really belong here for a user session? Those commands >> look like something that should be done only for the system dbus daemon >> to me... > > good observation, they should be dropped.
Just stumbled on some more issues related to this file, so, I had some time to reflect on why this service file was entirely broken, apart from the nitpick above, which won't do much unless you run systemd --user as root, which is quite unlikely. However, the dbus-daemon args are entirely wrong, and it bit me badly trying to figure out why dbus activation was horribly broken on my system to get things like gconfd-2 or gio working. For reference, here is the proper dbus.service file: ==== [Unit] Description=D-Bus System Message Bus Requires=dbus.socket [Service] ExecStart=/usr/bin/dbus-daemon --session --address=unix:path=%t/dbus/user_bus_socket --nofork --systemd-activation ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig OOMScoreAdjust=-900 ==== Note that we should probably not use "--address=systemd:" since it passes DBUS_SESSION_BUS_ADDRESS=systemd:,guid=<hash> to all dbus-activated services, which is entirely broken. However, we want to point to the user bus for this user, which is conveniently in %t/dbus/user_bus_socket, just as it is written in the user@.service as well. Dbus will append a ,guid=<hash> but I didn't see that causing a problem. I'm still seeing the initial systemd --user message: May 29 21:18:39 testbox systemd[4954]: Failed to register to bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. But that still seems harmless. Auke _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
