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)

— 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

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