[systemd-devel] Help with pam_systemd..

[Kok, Auke-jan H]

On Tue, May 29, 2012 at 7:56 PM, Kok, Auke-jan H
<auke-jan.h.kok at intel.com> wrote:
> On Tue, May 29, 2012 at 12:52 PM, Colin Guthrie <gmane at 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 at .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