Bug 920548

/run/user/0/dbus/ nore /run/user/0/dbus/user_bus_socket does not belong to systemd, the systemd socket is /run/user/0/systemd/private.  Even if systemd journald collects and forward the log messages

So why is systemd (or whoever) trying to open that socket if it doesn't exist?

that being said, there is no private dbus socket for root anyways:

akari:~ # find /run/user -! -type d
/run/user/10002/systemd/private
/run/user/490/systemd/private
/run/user/1000/systemd/private
akari:~ #

 linux:~ #  find /run/user -! -type d
 /run/user/0/systemd/private
 linux:~ # fuser /run/user/0/systemd/private
 /run/user/0/systemd/private: 31461
 linux:~ # ps 31461
   PID TTY      STAT   TIME COMMAND
 31461 ?        Ss     0:00 /usr/lib/systemd/systemd --user

Beside this

 linux:~ # grep -rs ListenStream= /usr/lib/systemd
 /usr/lib/systemd/system/rpcbind.socket:ListenStream=/run/rpcbind.sock
 /usr/lib/systemd/system/rpcbind.socket:ListenStream=0.0.0.0:111
 /usr/lib/systemd/system/rpcbind.socket:ListenStream=[::]:111
 /usr/lib/systemd/system/lvm2-lvmetad.socket:ListenStream=/run/lvm/lvmetad.socket
 /usr/lib/systemd/system/systemd-journal-gatewayd.socket:ListenStream=19531
 /usr/lib/systemd/system/pcscd.socket:ListenStream=/var/run/pcscd/pcscd.comm
 /usr/lib/systemd/system/cups.socket:ListenStream=/var/run/cups/cups.sock
 /usr/lib/systemd/system/cups.socket:ListenStream=631
 /usr/lib/systemd/system/avahi-daemon.socket:ListenStream=/run/avahi-daemon/socket
 /usr/lib/systemd/system/dbus.socket:ListenStream=/run/dbus/system_bus_socket
 /usr/lib/systemd/system/systemd-journald.socket:ListenStream=/run/systemd/journal/stdout

shows that socket for dbus is /run/dbus/system_bus_socket .... I've no idea which application triy to connect to /run/user/0/dbus/user_bus_socket.  Maybe this is a third party tool using dbus and was compiled against an other dbus package:

  https://bugs.freedesktop.org/show_bug.cgi?id=61301
  https://bugs.freedesktop.org/show_bug.cgi?id=61303

I don't have a /run/user/0 folder structure, and I don't have the matching systemd --user process either... possibly because my server is running in textmode (multi-user.target is the default), and root is not logged in locally either.

here's some additional info from another server:

v22014011974116376:~ # journalctl _PID=11900
-- Logs begin at Sat 2015-02-28 08:45:01 CET, end at Wed 2015-03-04 11:48:17 CET. --
Mar 01 13:10:01 v22014011974116376 /usr/sbin/cron[11900]: pam_unix(crond:session): session opened for user root by (uid=0)
Mar 01 13:10:02 v22014011974116376 /USR/SBIN/CRON[11900]: pam_unix(crond:session): session closed for user root
Mar 03 20:45:01 v22014011974116376 systemd[11900]: pam_unix(systemd-user:session): session opened for user wwwrun by (uid=0)
Mar 03 20:45:01 v22014011974116376 systemd[11900]: Failed to open private bus connection: Failed to connect to socket /run/user/30/dbus/user_bus_socket: No su
Mar 03 20:45:01 v22014011974116376 systemd[11900]: Starting Default.
Mar 03 20:45:01 v22014011974116376 systemd[11900]: Reached target Default.
Mar 03 20:45:01 v22014011974116376 systemd[11900]: Startup finished in 76ms.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Stopping Default.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Stopped target Default.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Starting Shutdown.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Reached target Shutdown.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Starting Exit the Session...
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Started Exit the Session.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Starting Exit the Session.
Mar 03 20:45:07 v22014011974116376 systemd[11900]: Reached target Exit the Session.
v22014011974116376:~ # crontab -u wwwrun -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.J7MBWc installed on Tue Feb 10 12:45:02 2015)
# (Cronie version 4.2)
*/15 * * * * /usr/bin/php -f /srv/www/htdocs/owncloud/cron.php

That is a tmpfs, aka a memory based file system:

 linux:~ # df /run
 Filesystem     1K-blocks  Used Available Use% Mounted on
 tmpfs            1027248  1896   1025352   1% /run

log in as root and do

 linux:~ # echo $XDG_RUNTIME_DIR 
 /run/user/0

that is if root requires to have a /run/user/0 it will be created by the session managment.

Beside this you may run

  grep -irs user_bus_socket /srv/www/

and see if something is found ;)

ok, so /run/user/0 does in fact exist, but that doesn't explain why a cronjob triggers an access to a dbus socket that does not exist...

(In reply to Mathias Homann from comment #8)

The cronjob is third party AFAICS from your comment #6

As root you may run

 : ${PRUNEFS="nfs NFS nfs4 afs proc smbfs devtmpfs iso9660 ncpfs coda devpts ftpfs devfs mfs sysfs shfs cifs"}
 prunefs_exp=$(echo $PRUNEFS |sed -re 's/([^ ][^ ]*)/-fstype \1 -o/g')
 find / -type d \( $prunefs_exp -fstype autofs \) -prune -o -print | xargs grep -s user_bus_socket

but be aware that this does scan every local file on your system for the string user_bus_socket.
Usage at your own risk

(In reply to Werner Fink from comment #9)
> (In reply to Mathias Homann from comment #8)
> 
> The cronjob is third party AFAICS from your comment #6

the cron job is part of the owncloud packages that are provided on OBS.

found this:

akari:~ # find / -type d \( $prunefs_exp -fstype autofs \) -prune -o -print | xargs grep -s user_bus_socket
/usr/lib/systemd/system/user@.service:Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket

which is part of systemd-208-32 from the last updates.

(In reply to Mathias Homann from comment #13)

You may consider an update to openSUSE 13.2 with systemd-210 or systemd-210 from Base:System:Legacy, see http://download.opensuse.org/repositories/Base:/System:/Legacy/openSUSE_13.1/

For systemd-208 there will be no update as this had caused a lot of trouble in past :(

(In reply to Werner Fink from comment #14)
> (In reply to Mathias Homann from comment #13)
> 
> You may consider an update to openSUSE 13.2 with systemd-210 or systemd-210
> from Base:System:Legacy, see
> http://download.opensuse.org/repositories/Base:/System:/Legacy/openSUSE_13.1/
> 
> For systemd-208 there will be no update as this had caused a lot of trouble
> in past :(

systemd-208 is simply too old for upstream patches.
Backports get too complex and can cause severe side effects.
Mathias, you were in cc in bug 918226 and know what can happen.
If you want to stay with you current systemd version, you should consider using one of the workarounds mentioned in bug 918226.

"WONTFIX"? I didn't know 13.1 was already end-of-life... anyway I believe that if the underlying problem in systemd can't be easily fixed in 13.1 then at least the various workarounds that minimize the effects of the problem should be rolled out as a package.

which info did you actually need?

(In reply to Mathias Homann from comment #16)
> "WONTFIX"? I didn't know 13.1 was already end-of-life... 

WONTFIX, because a fix is too risky and complex and there is a bunch of alternatives available.

> anyway I believe
> that if the underlying problem in systemd can't be easily fixed in 13.1 then
> at least the various workarounds that minimize the effects of the problem
> should be rolled out as a package.

Considering the alternatives, I don't see the need for this.
However, this is a community project, you are welcome to provide such a package. 
But much simpler is if you just update to OpenSUSE 13.2.
This is shipping systemd version 210 with a huge amount of code enhancements.
Still, if you experience the same problem with 13.2, please open a new bug.
For 13.2, we can do a fix if necessary.

(In reply to Mathias Homann from comment #17)
> which info did you actually need?

Werner was asking to test systemd version 210, that is available for 13.1 at:

http://download.opensuse.org/repositories/Base:/System:/Legacy/openSUSE_13.1/

Since I recently applied the recommended security patches to my 13.1 systems, I am also seeing a huge amount of these messages and an occasional segfault.

Is the only fix to either downgrade systemd or upgrade to 210?

(In reply to Don Hughes from comment #19)
> Since I recently applied the recommended security patches to my 13.1
> systems, I am also seeing a huge amount of these messages and an occasional
> segfault.
> 
> Is the only fix to either downgrade systemd or upgrade to 210?

Please try the testpackages provided in Bug 922536.
They also addresses the superfluous log messages.

*** This bug has been marked as a duplicate of bug 922536 ***