Comment 16 for bug 1053910

(In reply to comment #8)
> My other dbus instance is here:
> $ echo $DBUS_SESSION_BUS_ADDRESS
> unix:abstract=/tmp/dbus-4Lf6aHxvqg,guid=a5ec76744e9723954bcaa3f10000001e
>
> Also I can see it in netstat:
> $ netstat -nap --unix | grep LISTEN | grep dbus | head -n1
> unix 2 [ ACC ] STREAM LISTENING 13380 1970/dbus-daemon
> @/tmp/dbus-4Lf6aHxvqg
>
> But the problem is, that /tmp/dbus-4Lf6aHxvqg doesn't exist.

It's an "abstract Unix socket" which doesn't exist in the filesystem, which means that when dbus-daemon exits, it doesn't need to delete a Unix socket special file like it would when using normal Unix sockets. Its address is actually "\0/tmp/dbus-4Lf6aHxvqg" where \0 represents a NUL byte (that's also what the @ in netstat represents).

This is normal, on OSs that have abstract Unix sockets (Linux and possibly Solaris, but not *BSD).

> recvmsg(59, 0x7fffde52f3e0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily
> unavailable)

It is normal for an idle dbus-daemon to encounter EAGAIN. That just means "there are no more messages for you to read right now, try again later".

> Or maybe there is some better and cleaner way of diagnosing the problem.

dbus-monitor(1) and d-feet (a GUI application) might be helpful.

> Also how do I use --print-pid option in practical way to print actual PID of
> processes which are connecting to dbus?

That's not what that option does. It's nothing to do with the process IDs of D-Bus clients:

> kenorb 1970 0.0 0.1 30000 5856 ? Ss Sep19 0:07
> //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

Early in its startup, that process will have printed its own pid (1970 in this case) to file descriptor 5, and its address to file descriptor 7. Those file descriptors were pipes to dbus-launch, which was its parent process: it's how dbus-launch finds out what values to put in your GUI session's $DBUS_SESSION_BUS_ADDRESS and $DBUS_SESSION_BUS_PID. Once the session is up and running, those options have no further effect.