dbus: [system] Nie udało się aktywować usługi „org.freedesktop.login1”: upłynął limit czasu

25

W dzienniku systemowym jednego z moich serwerów wciąż pojawiają się następujące komunikaty o błędach:

# 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'

Wydaje się, że korelują one z logowaniami FTP na demonie 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.

Jednak same loginy FTP wydają się działać bez problemów dla użytkownika. Mam kilka innych serwerów z systemem ProFTPd, ale jak dotąd nigdy nie wystąpiły te błędy.

Mogą być jednak związane z ostatnią aktualizacją z Debian 7 do Debian 8.

Jakieś pomysły, co wiadomość chce mi powiedzieć, a nawet co je powoduje?

Próbowałem już zrestartować demony dbus i proftpd, a nawet serwer, i upewniłem się, że gniazdo DBUS / var / run / dbus / system_bus_socket istnieje, ale do tej pory komunikaty przychodzą.

EDYCJA: Dane wyjściowe dziennika Journal zgodnie z żądaniem w komentarzu:

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

I więcej danych z dziennika:

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)
linux debian d-bus proftpd lathspell
źródło
Co systemctl status -l dbus-org.freedesktop.login1.servicezgłasza się, gdy działa jako root? Czy coś wyróżnia się w wynikach journalctl(szczególnie w czasach komunikatów o błędach)?
Ferenc Wágner
Dodałem wynik działania systemctl / journalctl powyżej.
lathspell
1
Czy ponowne uruchomienie logind ( systemctl restart systemd-logind) pomaga?
Ferenc Wágner,
Jak dotąd pomogło to na cały dzień. Ponownie uruchomiłem ponownie serwer, aby sprawdzić, czy problem powraca, ponieważ proste ponowne uruchomienie nigdy nie pomogło, zanim zgłosiłem problem tutaj.
lathspell
Wydaje się, że ponowne uruchomienie rozwiązało problem. Niemal rozczarowujące;) Co takiego zrobiło to, że proste „zamknięcie -r teraz” nie mogło naprawić? Dzięki za pomoc!
lathspell

Odpowiedzi:

19

Uruchom ponownie logind:

# systemctl restart systemd-logind

Uwaga: ponowne uruchomienie dbus ponownie przerwie ich połączenie.

Ferenc Wágner
źródło
To rozwiązuje problem tylko tymczasowo. Po pewnym czasie (miesiącach) ponownie pojawia się ten sam problem.
Ortomala Lokni
3
# systemctl restart systemd-logind Nie można zrestartować systemd-logind.service: Przekroczono limit czasu połączenia Zobacz dzienniki systemowe i „status systeml systemd-logind.service”, aby uzyskać szczegółowe informacje.
Dalibor Filus
I widziałeś ich, @DaliborFilus?
Ferenc Wágner,
≤systemctl status php7.0-fpmpowiedział mi to samo, więc doszedłem do wniosku, że uruchomienie systemu systemctl nie ma wtedy sensu. To był serwer produkcyjny, musiałem działać szybko. Spróbuję następnym razem.
Dalibor Filus
Naprawiono to tutaj, gdzie prawdziwym punktem bólu było naprawdę wolne logowanie SSH. W moim przypadku problem może być związany z ostatnią aktualizacją systemową, a następnie nie może być ponownie uruchamiany. needs-restarting(wciąż) mówi, że systemd potrzebuje ponownego uruchomienia.
Nicolas Melay
7

Ponowne uruchomienie było jedynym rozwiązaniem, które działało dla mnie. Zabiłem niekontrolowany proces dbus i inne rzeczy zawiodły.

Tak się stało, gdy próbowałem ponownie załadować 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 jest wadliwy.

Ryan Bishop
źródło
1

Dzisiaj spotkałem się z tym samym problemem i dowiedziałem się, że był on początkowo spowodowany przez usługę pochłaniającą całą dostępną pamięć. Znalazłem powiązane wiersze dziennika, które wyjaśniły, że jest to spowodowane przydzieleniem pamięci w dzienniku / 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

Aby znaleźć usługę przy użyciu większości pamięci, wykonałem to:

ps aux --sort=-%mem

Aby rozwiązać problem, najpierw próbowałem zwolnić pamięć, ale nadal systemd-logind nie mógł się uruchomić. Dlatego musiałem zrestartować serwer i problem został rozwiązany.

Michael Aicher
źródło
1

Ponowne uruchomienie tylko usługi logd systemd nie wystarczy, po prostu opóźnia główny problem.

Wydaje się, że jest to spowodowane zbyt dużą liczbą plików zgromadzonych w „/ run / systemd / system /”, utworzonych przez usługę i niepoprawnie wyczyszczonych, szczególnie na hostach z dużą liczbą logowań. W końcu po pewnym czasie zaczną się pojawiać dziwne zachowania, takie jak hostnamectl, który niczego nie zgłasza, lub raporty timedatectl. Nie można wysłać zapytania do serwera: przekroczono limit czasu połączenia i inne dziwne rzeczy. Jak również objawy zgłaszane pierwotnie.

Jednym z obejść jest usunięcie wszystkich plików „session - *. Scope” i zrestartowanie systemu. W takim przypadku ponowne uruchomienie hosta nie jest konieczne. Prawdopodobnie jest to związane z błędem w systemd i dbus, miejmy nadzieję, że w następnych aktualizacjach zostaną naprawione.

Daniel Velichkov
źródło
-3

Po prostu zainstaluj ponownie systemd.

apt install --reinstall systemd

to rozwiązuje problem dla mnie na wielu maszynach wirtualnych

TheBuzzzzzz
źródło