dbus: [sistema] Error al activar el servicio 'org.freedesktop.login1': se agotó el tiempo de espera

25

Sigo recibiendo los siguientes mensajes de error en el syslog de uno de mis servidores:

# tail /var/log/syslog
Oct 29 13:48:40 myserver dbus[19617]: [system] Failed to activate service 'org.freedesktop.login1': timed out
Oct 29 13:48:40 myserver dbus[19617]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Oct 29 13:49:05 myserver dbus[19617]: [system] Failed to activate service 'org.freedesktop.login1': timed out
Oct 29 13:49:05 myserver dbus[19617]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'

Parecen correlacionarse con los inicios de sesión FTP en el demonio ProFTPd:

# tail /var/log/proftpd/proftpd.log
2015-10-29 13:48:40,433 myserver proftpd[17872] myserver.example.com (remote.example.com[192.168.22.33]): USER switch: Login successful.
2015-10-29 13:48:40,460 myserver proftpd[17872] myserver.example.com (remote.example.com[192.168.22.33]): FTP session closed.
2015-10-29 13:48:40,664 myserver proftpd[17881] myserver.example.com (remote.example.com[192.168.22.33]): FTP session opened.
2015-10-29 13:49:05,687 myserver proftpd[17881] myserver.example.com (remote.example.com[192.168.22.33]): USER switch: Login successful.
2015-10-29 13:49:05,705 myserver proftpd[17881] myserver.example.com (remote.example.com[192.168.22.33]): FTP session closed.
2015-10-29 13:49:05,908 myserver proftpd[17915] myserver.example.com (remote.example.com[192.168.22.33]): FTP session opened.

Sin embargo, los inicios de sesión FTP parecen funcionar sin problemas para el usuario. Tengo un par de otros servidores que también ejecutan ProFTPd, pero hasta ahora nunca obtuve estos errores.

Sin embargo, podrían estar relacionados con una actualización reciente de Debian 7 a Debian 8.

¿Alguna idea de lo que el mensaje quiere decirme o incluso qué los causa?

Ya intenté reiniciar los demonios dbus y proftpd e incluso el servidor y me aseguré de que el socket DBUS / var / run / dbus / system_bus_socket exista pero hasta ahora los mensajes siguen llegando.

EDITAR: La salida de journalctl como se solicita en el comentario:

root@myserver:/home/chammers# systemctl status -l dbus-org.freedesktop.login1.service
● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: active (running) since Tue 2015-10-27 13:23:32 CET; 1 weeks 0 days ago
     Docs: man:systemd-logind.service(8)
           man:logind.conf(5)
           http://www.freedesktop.org/wiki/Software/systemd/logind
           http://www.freedesktop.org/wiki/Software/systemd/multiseat
 Main PID: 467 (systemd-logind)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-logind.service
           └─467 /lib/systemd/systemd-logind

Oct 28 10:15:25 myserver systemd-logind[467]: New session c3308 of user switch.
Oct 28 10:15:25 myserver systemd-logind[467]: Removed session c3308.
Oct 28 10:15:25 myserver systemd-logind[467]: New session c3309 of user switch.
Oct 28 10:15:25 myserver systemd-logind[467]: Removed session c3309.
Oct 28 10:15:25 myserver systemd-logind[467]: New session c3310 of user switch.
Oct 28 10:15:25 myserver systemd-logind[467]: Removed session c3310.
Oct 28 10:15:25 myserver systemd-logind[467]: New session c3311 of user switch.
Oct 28 10:15:25 myserver systemd-logind[467]: Removed session c3311.
Oct 28 10:19:52 myserver systemd-logind[467]: New session 909 of user chammers.
Oct 28 10:27:11 myserver systemd-logind[467]: Failed to abandon session scope: Transport endpoint is not connected

Y más salida de journalctl:

Nov 03 16:21:19 myserver dbus[19617]: [system] Failed to activate service 'org.freedesktop.login1': timed out
Nov 03 16:21:19 myserver proftpd[23417]: pam_systemd(proftpd:session): Failed to create session: Activation of org.freedesktop.login1 timed out
Nov 03 16:21:19 myserver proftpd[23418]: pam_systemd(proftpd:session): Failed to create session: Activation of org.freedesktop.login1 timed out
Nov 03 16:21:19 myserver proftpd[23417]: pam_unix(proftpd:session): session closed for user switch
Nov 03 16:21:19 myserver proftpd[23418]: pam_unix(proftpd:session): session closed for user switch
Nov 03 16:21:19 myserver proftpd[23420]: pam_unix(proftpd:session): session opened for user switch by (uid=0)
Nov 03 16:21:19 myserver dbus[19617]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Nov 03 16:21:19 myserver proftpd[23421]: pam_unix(proftpd:session): session opened for user switch by (uid=0)

— encantamiento
fuente

¿Qué systemctl status -l dbus-org.freedesktop.login1.serviceinforma cuando se ejecuta como root? ¿Se destaca algo en la salida de journalctl(especialmente en los tiempos de los mensajes de error)?

— Ferenc Wágner

He agregado la salida de systemctl / journalctl arriba.

— Lathspell

1

¿Reiniciar logind ( systemctl restart systemd-logind) ayuda?

— Ferenc Wágner el

Hasta ahora ayudó por el día. Ahora he reiniciado el servidor para ver si el problema regresa ya que un reinicio simple nunca ayudó antes de informar el problema aquí.

— encantamiento 5/15

El reinicio parece haber solucionado el problema. Casi decepcionante;) ¿Qué hizo que un simple "shutdown -r now" no pudiera solucionar? ¡Gracias por tu ayuda!

— Lathspell

19

Reiniciar logind:

# systemctl restart systemd-logind

Tenga en cuenta que reiniciar dbus interrumpirá su conexión nuevamente.

— Ferenc Wágner
fuente

Esto resuelve el problema solo temporalmente. Después de un tiempo (meses) reaparece el mismo problema.

— Ortomala Lokni

3

# systemctl restart systemd-logind No se pudo reiniciar systemd-logind.service: se agotó el tiempo de espera de la conexión Consulte los registros del sistema y 'systemctl status systemd-logind.service' para obtener más detalles.

— Dalibor Filus el

¿Y los viste @DaliborFilus?

— Ferenc Wágner

≤systemctl status php7.0-fpmme dijo lo mismo, así que pensé que ejecutar systemctl no tenía sentido en ese momento. Este era un servidor de producción, tuve que actuar rápidamente. Lo intentaré la próxima vez.

— Dalibor Filus el

Lo arreglé aquí, donde el verdadero punto de dolor era un inicio de sesión SSH realmente lento. En mi caso, el problema podría estar relacionado con una actualización reciente de systemd y no reiniciar después de eso. needs-restarting(todavía) dice que systemd necesita un reinicio.

— Nicolas Melay

7

Reiniciar fue la única solución que funcionó para mí. Maté el fugitivo proceso de dbus y otras cosas fallaron.

Esto es lo que sucedió cuando intenté volver a cargar httpd-

Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.PolicyKit1 timed out (g-dbus-error-quark, 20)
Failed to reload httpd.service: Connection timed out

Centos7 tiene errores.

— Ryan Bishop
fuente

1

Me enfrenté al mismo problema hoy y descubrí que inicialmente fue causado por un servicio que consumía toda la memoria disponible. Encontré las líneas de registro relacionadas, que dejaron en claro que es causado por la asignación de memoria en el registro / var / log / messages .

systemd: Starting Session 750154 of user root.
systemd: Failed to fork: Cannot allocate memory
systemd: Assertion 'pid >= 1' failed at src/core/unit.c:1997, function unit_watch_pid(). Aborting.
systemd: Caught <ABRT>, cannot fork for core dump: Cannot allocate memory
systemd: Freezing execution.
dbus[697]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out

Para averiguar el servicio utilizando la mayor parte de la memoria, ejecuté esto:

ps aux --sort=-%mem

Para resolver el problema, primero intenté liberar la memoria, pero aún así systemd-logind no pudo iniciarse. Por lo tanto, tuve que reiniciar el servidor y el problema se resolvió.

— Michael Aicher
fuente

1

Reiniciar solo el servicio systemd-logind no es suficiente, solo pospone el problema principal.

Parece que esto es causado por demasiados archivos almacenados en '/ run / systemd / system /', creados por el servicio y no limpiados adecuadamente, especialmente en hosts con muchos inicios de sesión. Eventualmente, después de algún tiempo, comenzará a ver un comportamiento extraño, como hostnamectl no informa de nada, o timedatectl informa No se pudo consultar el servidor: se agotó el tiempo de espera de la conexión y otras cosas extrañas. También los síntomas informados originalmente.

Una solución alternativa es eliminar todos los archivos 'session - *. Scope' y reiniciar systemd. No es necesario reiniciar el host en ese caso. Esto probablemente esté relacionado con un error en systemd y dbus, con suerte en las próximas actualizaciones se solucionarán.

— Daniel Velichkov
fuente

-3

Simplemente reinstale systemd.

apt install --reinstall systemd

esto resuelve el problema para mí en muchas máquinas virtuales

— TheBuzzzzzz
fuente