[systemd-devel] Failed to connect to socket /org/freedesktop/systemd1/private

[Daniel Drake]

On 9 May 2011 22:46, Lennart Poettering <lennart at poettering.net> wrote:
> You are lacking autofs4 support in the kernel. You should fix this first.

I'm not, autofs4 is present, we're working on figuring out on why
systemd complains at
https://bugs.freedesktop.org/show_bug.cgi?id=36993

> Your udev in your initrd is a different version than on your system. You
> should really fix that too.

Ah, that explains that part. Done.

> /etc/mtab is not a symlink to /proc/mounts. Please fix.

Done.

> Your systemd userspace seems to be out-of-date, and not from the same
> package that installed /bin/systemd. i.e. the abstract namespace socket
> /org/freedesktop/systemd1/private was used in older systemd versions,
> but has since moved to /run/systemd/private. Your userspace still tries
> to access the old socket, but systemd 26 (which you appear to be
> running) uses the new one.

This image is freshly made, starting from an empty disk, from Fedora
rawhide as of yesterday, so there should be no mixing going on.

But I've debugged it a little to see why its using the wrong path:

We are reaching bus_connect() in dbus-common.c.
It first tries to connect to /run/systemd/private, but this fails.
It then falls back on /org/freedesktop/systemd1/private. This fails
too. So it then returns error and it only logs the last error (which
was about /org/freedesktop/systemd1/private)

If I log the error after it tries to connect to /run/systemd/private, I get:
Failed to connect to socket /run/systemd/private: No such file or directory

Indeed, there's nothing at that path, and the only thing in
/run/systemd/ is an empty directory at /run/systemd/ask-password

So I then looked on the systemd side of things, bus_init_private() in
dbus.c does create this socket just fine (via to dbus_server_listen).
So the question is when and why does it disappear? I sprinkled debug
statements throughout the code and determined that the socket
disappears after manager_loop() has iterated around 47 times.

Does this give you any ideas? Any suggestions for next debugging
steps? Is there an easy way to make manager_loop() log exactly what it
does on each iteration?

Thanks,
Daniel