systemd: user_bus_socket: No such file or directory

Deutsch (German) Installation/Administration
1

Hallo,

seit einiger Zeit beobachte ich folgende Einträge in meinem System-Log:

…]
/usr/sbin/cron[3023]: pam_unix(crond:session): session opened for user wwwrun by (uid=0)
systemd[1]: Starting user-30.slice.
systemd[1]: Created slice user-30.slice.
systemd[1]: Starting User Manager for 30…
systemd[1]: Starting Session 3 of user wwwrun.
systemd[1]: Started Session 3 of user wwwrun.
/USR/SBIN/CRON[3025]: (wwwrun) CMD ( php /srv/www/cacti/poller.php > /dev/null 2>&1)
/USR/SBIN/CRON[3023]: pam_unix(crond:session): session closed for user wwwrun
systemd[3024]: pam_unix(systemd-user:session): session opened for user wwwrun by (uid=0)
systemd[3024]: Failed to open private bus connection: Failed to connect to socket /run/user/30/dbus/user_bus_socket: No such file or directory
systemd[3024]: Stopped target Sound Card.
systemd[3024]: Starting Default.
systemd[3024]: Reached target Default.
systemd[3024]: Startup finished in 23ms.
systemd[1]: Started User Manager for 30.
systemd[1]: Stopping User Manager for 30…
systemd[3024]: Stopping Default.
systemd[3024]: Stopped target Default.
systemd[3024]: Starting Shutdown.
systemd[3024]: Reached target Shutdown.
systemd[3024]: Starting Exit the Session…
systemd[1]: Stopped User Manager for 30.
systemd[1]: Stopping user-30.slice.
systemd[1]: Removed slice user-30.slice.
…]

Mir geht es um die Markierte Meldung. Das diese sich wegen dem Cron-Job wiederholt ist mir klar. Aber warum kommt die Fehlermeldung und was kann ich dagegen tun?

Ich verwende 13.1 x64; Kein Dist-Upgrade; Aktuelle Updates/Patches werden eingespielt.

Während des System-Start ist mir die folgende Meldung aufgefallen:

…]
systemd[1]: Starting Local File Systems (Pre).
systemd[1]: Reached target Local File Systems (Pre).
systemd[1]: Mounting Runtime Directory…
systemd[1]: var-run.mount: Directory /var/run to mount over is not empty, mounting anyway.
systemd[1]: Mounting Lock Directory…
systemd-modules-load[248]: Inserted module ‘sg’
systemd[1]: Started Load Kernel Modules.
systemd[1]: Mounted Configuration File System.
systemd[1]: Mounted FUSE Control File System.
systemd[1]: Started udev Kernel Device Manager.
systemd[1]: Mounted Runtime Directory.
systemd[1]: Mounted Lock Directory.
…]

Ich bin mir nicht sicher ob es einen Zusammenhang gibt.

Evtl. hat jemand eine Idee?

Viele Grüße!

2

Soweit ich weiß, gabs beim letzten systemd Update für systemd ein Problem, dass u.a. auch solch eine Fehlermeldung verursachen konnte.
Allerdings sollte das mit einem Update am Samstag behoben sein, und es war ja eigentlich so, dass systemd komplett abstürzte…
Aber trotzdem, welche systemd Version hast du installiert?

rpm -qi systemd

Was ist eigentlich User 30 bei dir? Sh. /etc/passwd.
Bei mir ist das Apache bzw. wwwrun. Aber /run/user/30/ existiert bei mir nicht mal, obwohl Apache läuft. (bin aber auf 13.2)

Ansonsten: dbus.service ist enabled und läuft?

systemctl status dbus

systemd[1]: var-run.mount: Directory /var/run to mount over is not empty, mounting anyway.

Tja, das scheint wohl klar zu sein.
/var/run wird gemounted, aber ist nicht leer.
Wahrscheinlich war es irgendwann mal nicht gemountet, und deshalb wurden Dateien in /var/run (also dem Mount-Point) auf der Root-Partition angelegt.
Ich würde vorschlagen du bootest von einer LiveCD (oder füge “init=/bin/sh” zu den Boot-Optionen hinzu durch drücken von ‘e’ im Bootmenü), und räumst /var/run/ leer.

Ist aber nur eine Warnung und sollte keine Probleme verursachen, denke ich…

Ich bin mir nicht sicher ob es einen Zusammenhang gibt.

Tja, keine Ahnung ob ein Zusammenhang besteht, eher nicht. Aber /run ist ja nur ein bind-mount auf /var/run (bzw. umgekehrt), also beide sind im Prinzip dasselbe.

3

Hallo wolfi323,

ich taste mich mal langsam (von hinten nach vorne) ran…

Das Verzeichnis /var/run habe ich via Live-CD gemountet und geleert. Die Fehlermeldung erscheint nicht mehr, und steht auch nicht im Zusammenhang mit der Ersten (Failed to connect to socket) Meldung. Den diese kommt immer noch.

Das Problem mit systemd hatte ich. Die aktuelle Version funktioniert aber wieder. Das Problem wurde hier: https://forums.opensuse.org/showthread.php/505443-systemd-1-segfault beschrieben.

Die Ausgabe von rpm -qi systemd:

# rpm -qi systemd
Name        : systemd
Version     : 208
Release     : 32.1
Architecture: x86_64
Install Date: Mon Feb 23 07:38:56 2015
Group       : System/Base
Size        : 6235015
License     : LGPL-2.1+
Signature   : RSA/SHA256, Sun Feb 22 20:00:11 2015, Key ID b88b2fd43dbdc284
Source RPM  : systemd-208-32.1.src.rpm
Build Date  : Fri Feb 20 14:49:34 2015
Build Host  : cloud122
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : http://www.freedesktop.org/wiki/Software/systemd
Summary     : A System and Session Manager

Der D-BUS Daemon läuft:

# systemctl status dbus
dbus.service - D-Bus System Message Bus
   Loaded: loaded (/usr/lib/systemd/system/dbus.service; static)
   Active: active (running) since Wed 2015-02-25 20:40:33 CET; 15h ago
     Docs: man:dbus-daemon(1)
 Main PID: 372 (dbus-daemon)
   CGroup: /system.slice/dbus.service
           └─372 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

systemd[1]: Starting D-Bus System Message Bus...
systemd[1]: Started D-Bus System Message Bus.

Und ja, 30 ist die userid von wwwrun.

Das Verzeichnis /run/user/ existiert. Hier ist meine userid (1000) eingetragen. Userid 0 (root) oder 30 (wwwrun) fehlen. Evtl. werden diese pro Session angelegt? Dann scheint der Mechanismus aber nicht zu funktionieren.

Das System läuft hier ohne Tastatur oder Monitor im Textmodus (ohne X-Server). Ich bringe den D-BUS mit dem X-Server in Verbindung. Möglicherweise liegt hier das Problem?

Vielleicht kann hierzu jemand etwas sagen. Die Serverdienste funktionieren, auch mit den Meldungen.

Viele Grüße!

4

Ja, die werden pro Session angelegt. /run und /var/run sind tmpfs, also nirgendwo auf der Festplatte vorhanden (sie existieren nur im RAM) und bei jedem Neustart leer.

Das System läuft hier ohne Tastatur oder Monitor im Textmodus (ohne X-Server). Ich bringe den D-BUS mit dem X-Server in Verbindung. Möglicherweise liegt hier das Problem?

D-BUS hat absolut gar nichts mit dem X-Server zu tun und soll sogar in naher Zukunft in den Kernel integriert werden.

Vielleicht kann hierzu jemand etwas sagen. Die Serverdienste funktionieren, auch mit den Meldungen.

Tja, dann kannst du das wahrscheinlich getrost ignorieren.

Die Meldung kommt von systemd, aber ich weiß jetzt im Moment auch nicht genau warum.
Wie gesagt, hier mit 13.2 hab ich auch kein /run/user/30 (obwohl Apache läuft), und ich bekomme auch keine solche Meldung.
Und nichtmal für meinem Standard-User mit dem ich in KDE eingeloggt bin, existiert /run/user/$UID/dbus/ (/run/user/$UID/ natürlich schon).

Hat aber wohl was mit der verhergehenden Meldungen zu tun:

/usr/sbin/cron[3023]: pam_unix(crond:session): session opened for user wwwrun by (uid=0)
systemd[1]: Starting user-30.slice.
systemd[1]: Created slice user-30.slice.
systemd[1]: Starting User Manager for 30...
systemd[1]: Starting Session 3 of user wwwrun.
systemd[1]: Started Session 3 of user wwwrun.
/USR/SBIN/CRON[3025]: (wwwrun) CMD ( php /srv/www/cacti/poller.php > /dev/null 2>&1)
/USR/SBIN/CRON[3023]: pam_unix(crond:session): session closed for user wwwrun
systemd[3024]: pam_unix(systemd-user:session): session opened for user wwwrun by (uid=0)

Die habe ich auch nicht, aber ich hab cacti nicht installiert. Vermutlich liegt das einfach nur an dem Cron-Job, der scheinbar irgendwas (php /srv/www/cacti/poller.php) als user wwwrun aufruft, was natürlich eine User-Session startet…

Das “Problem” hört sich aber wie hier an, wurde scheinbar in späteren systemd Versionen behoben:
http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/10982
Wenn ich das richtig verstehe, gibts eigtl. kein Problem (außer der Meldung).

5

Ja, die werden pro Session angelegt. /run und /var/run sind tmpfs, also nirgendwo auf der Festplatte vorhanden (sie existieren nur im RAM) und bei jedem Neustart leer.

Ok. Genauer werden die Verzeichnisse unter /run/user/ von einem (vermute ich) Dienst bedient. Z.B. wenn ich eine Anmeldung via SSH mache, wird dort ein userid-Unterverzeichnis angelegt; Melde ich mich wieder ab, wird dieses Unterverzeichnis gelöscht - sofort - nicht erst bei Neustart.
Interessant wäre nun, wer das Verzeichnis /run/user bedient? Noch Interessanter wird dies durch die Aussage, Apache läuft bei Dir. Ich habe zwar Apache installiert, aber seit ein paar Tagen (ich glaube es war ein php-Update) startet dieser nicht mehr. Der CronJob ist hiervon nicht betroffen.
Es ist Richtig, dass der Cacti-Poller via Cron ein Skript startet, und regelmäßig Webseiten aufbereitet. Daher auch der wwwrun User.

Ok. Ich werde mir den systemd-Thread mal anschauen. Ansonsten kann der Thread geschlossen werden.

6

Ja. Das wird von PAM gemacht soweit ich weiß.

Interessant wäre nun, wer das Verzeichnis /run/user bedient? Noch Interessanter wird dies durch die Aussage, Apache läuft bei Dir. Ich habe zwar Apache installiert, aber seit ein paar Tagen (ich glaube es war ein php-Update) startet dieser nicht mehr. Der CronJob ist hiervon nicht betroffen.
Es ist Richtig, dass der Cacti-Poller via Cron ein Skript startet, und regelmäßig Webseiten aufbereitet. Daher auch der wwwrun User.

Naja, der cron Job benutzt ja nicht Apache. Er läuft nur als Benutzer “wwwrun”, d.h. eine Benutzersitzung wird gestartet und der Befehl ausgeführt.

Dass Apache nicht läuft, ist wohl davon unabhängig.
“sudo systemctl status apache2” sollte weiter Aufschluss darüber geben warum er nicht läuft.

7

Hallo wolfi323,

seit dem letzten php5 Update funktioniert der Apache wieder. Bis auf den Schönheitsfehler im Zusammenspiel mit PAM und Cron funktioniert alles wie es soll. Von meiner Seite aus, schliesse ich den Thread.

Vielen Dank!

8

Freut mich zu hören! :slight_smile:

Bis auf den Schönheitsfehler im Zusammenspiel mit PAM und Cron funktioniert alles wie es soll.

Tja, was ähnliches wurde inzwischen auch bei openSUSE als Bug gemeldet:
920548 – systemd fills my logfiles with spam messages (da gehts zwar nicht um user 30, sondern 0, aber das “Problem” ist im Prinzip das gleiche)

Allerdings wird das (und andere Sachen) in 13.1 eher nicht gefixt werden wegen der schlechten Erfahrungen mit dem letzten systemd Update…
Falls dich die Meldungen stören, gibts scheinbar aber doch Möglichkeiten sie loszuwerden (Ändern des systemd Log-Levels z.B.)
Aber wie gesagt, diese Meldung ist an sich harmlos.