Powolne logowanie ssh - Upłynął limit czasu aktywacji org.freedesktop.login1

39

Na jednym z moich serwerów zauważyłem naprawdę opóźnienie logowania SSH.

Łączenie za pomocą opcji ssh -vvv opóźnienie występuje debug1: Entering interactive session.

wyciąg z połączenia:

debug1: Authentication succeeded (publickey).
Authenticated to IP_REDACTED ([IP_REDACTED]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1

używając opisanej tutaj metody wygenerowałem wyjście strace i zauważyłem linię, 14:09:53.676004 ppoll([{fd=5, events=POLLIN}], 1, {24, 999645000}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 0}) <25.020764>która zajmuje 25 sekund.

wyciąg z wyjścia strace:

14:09:53.675567 clock_gettime(CLOCK_MONOTONIC, {4662549, 999741404}) = 0 <0.000024>
14:09:53.675651 recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"l\4\1\1\n\0\0\0\2\0\0\0\215\0\0\0\1\1o\0\25\0\0\0", 24}], msg_controll
en=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 <0.000024>
14:09:53.675744 recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"/org/freedesktop/DBus\0\0\0\2\1s\0\24\0\0\0"..., 146}], msg_controllen
=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 146 <0.000025>
14:09:53.675842 recvmsg(5, 0x7ffe0ff1dfa0, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailab
le) <0.000023>
14:09:53.675925 clock_gettime(CLOCK_MONOTONIC, {4662550, 96075}) = 0 <0.000024>
14:09:53.676004 ppoll([{fd=5, events=POLLIN}], 1, {24, 999645000}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 0}) <25.020764>
14:10:18.696865 recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{"l\3\1\0013\0\0\0\3\0\0\0m\0\0\0\6\1s\0\5\0\0\0", 24}], msg_controllen=0,     msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 24 <0.000017>
14:10:18.696944 recvmsg(5, {msg_name(0)=NULL, msg_iov(1)=[{":1.10\0\0\0\4\1s\0#\0\0\0org.freedesktop."..., 155}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_CMSG_CLOEXEC) = 155 <0.000018>

W odpowiednim momencie zauważyłem wpis w dziennikach uwierzytelniania:

Jul 21 14:10:18 click sshd[8165]: pam_systemd(sshd:session): Failed to create session: Activation of org.freedesktop.login1 timed out

Nie wiem wystarczająco dużo o tym, po co próbuje sondować i dlaczego zajmuje teraz 25 sekund na tym konkretnym serwerze.

Te journalctl -u systemd-logindpokazy dowodzenia

Jul 20 11:33:06 click systemd-logind[19415]: Failed to abandon session scope: Transport endpoint is not connected
Jul 21 05:04:54 myhost systemd[1]: Started Login Service.
Jul 21 12:15:30 myhost systemd[1]: Started Login Service.
Jul 21 12:17:04 myhost systemd[1]: Started Login Service.
Jul 21 12:49:55 myhost systemd[1]: Started Login Service.
Jul 21 13:57:05 myhost systemd[1]: Started Login Service.
Jul 21 13:58:49 myhost systemd[1]: Started Login Service.
Jul 21 14:01:55 myhost systemd[1]: Started Login Service.
Jul 21 14:08:32 myhost systemd[1]: Started Login Service.
Jul 21 14:09:53 myhost systemd[1]: Started Login Service.
Jul 21 14:19:08 myhost systemd[1]: Started Login Service.
Jul 21 14:21:26 myhost systemd[1]: Started Login Service.
Jul 21 14:22:37 myhost systemd[1]: Started Login Service.
Jul 21 14:25:20 myhost systemd[1]: Started Login Service.
Jul 21 14:30:27 myhost systemd[1]: Started Login Service.
Jul 21 15:02:56 myhost systemd[1]: Started Login Service.

Wydanie polecenia systemctl restart systemd-logind.servicenaprawia to (prawdopodobnie na razie).

O czym Activation of org.freedesktop.login1to wspomina? Czy jest jakiś sposób, aby zapobiec ponownemu uruchomieniu logind w przyszłości? Spodziewam się, że z czasem będę mieć ten problem z resztą serwerów, którymi zarządzam.

Właśnie zauważyłem, że zaczyna się to dziać na innym serwerze. 

$ sudo service systemd-logind status

● systemd-logind.service - Login Service
   Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
   Active: active (running) since Tue 2015-06-16 14:10:57 BST; 1 months 12 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: 1701 (systemd-logind)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-logind.service
           └─1701 /lib/systemd/systemd-logind

Jul 28 13:16:21 myhost systemd[1]: Started Login Service.
Jul 28 13:16:47 myhost systemd[1]: Started Login Service.
Jul 28 16:09:23 myhost systemd[1]: Started Login Service.
Jul 28 16:09:49 myhost systemd[1]: Started Login Service.
Jul 28 16:10:15 myhost systemd[1]: Started Login Service.
Jul 28 16:10:41 myhost systemd[1]: Started Login Service.
Jul 28 22:50:19 myhost systemd[1]: Started Login Service.
Jul 29 05:00:15 myhost systemd[1]: Started Login Service.
Jul 29 11:00:20 myhost systemd[1]: Started Login Service.
Jul 29 11:09:56 myhost systemd[1]: Started Login Service.

EDIT - rozszerzone journalctlwyjście.

EDIT2 - dodano status logd systemd, jak zasugerowano w komentarzach, gdy zauważyłem, że zaczyna się na innym serwerze.

AKTUALIZACJA - Zaczyna się to dziać z resztą moich serwerów Jessie. Czy tylko ja tego doświadczam? Musi być jakaś poprawka inna niż zrestartowanie systemd-logind, czy ktoś ma jakieś przemyślenia?

Raport o błędzie Debiana dotyczący tego 770135 .

ssh  debian  pam  systemd 
— Alasdair
źródło
Przydałoby się zobaczyć wyjście systemcts status systemd-logindprzed restartem, aby zobaczyć, co było z nim nie tak (wyjście, niepowodzenie, cokolwiek). ppolljest tylko mediatorem, który czeka na odpowiedź systemd, więc nie można go winić.
— Jakuje
nie ma systemctspolecenia
— Alasdair,
Przepraszam. systemctloczywiście
— Jakuje
Myślałem, że o to ci chodzi, ale chciałem mieć pewność. Czy to nie to samo wyjście, jakie jest dostępne z poleceniajournalctl -u systemd-logind
— Alasdair
powinien pokazywać dziennik, ale także status samej usługi.
— Jakuje

Odpowiedzi:

48

Dzieje się tak, gdy dbus jest restartowany, ale systemd-logind nie jest restartowany. Po prostu wykonaj następujące czynności:

systemctl restart systemd-logind

Rozwiązanie jest stąd: https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/

— asv
źródło
1
Zgłoszone już pytanie, raport o błędach wciąż nie został rozwiązany, ale dziękuję za przywrócenie go.
— Alasdair,
Uwaga: może to również dać „pętlę logowania” w zwykłym programie witającym lightdm; obowiązuje to samo rozwiązanie.
— młot
1

Za pomocą:

systemctl restart systemd-logind

rozwiązuje problem tylko tymczasowo.

Jednym z obejść jest usunięcie wszystkich .scopeplików z zadania cron, jak podano tutaj .

* 2,14 * * * root /bin/rm -f /run/systemd/system/*.scope

Powiązany raport o błędach systemowych znajduje się tutaj: wyciek jednostek zakresu spowalnia „systemctl list-unit-files” i opóźnia logowanie .

Wygląda na to, że w rzeczywistości jest to błąd dbus: zepsute liczenie w locie unix fd, co zostało rozwiązane w wersji dbus 1.11.10

Aby trwale naprawić ten błąd, musisz tylko poczekać, aż ta wersja dbus pojawi się w twojej dystrybucji. Na razie Debian Stretch jest na dbus 1.10.18, Ubuntu 17.04 (Zesty) na 1.10.10, CentOS 7 na dbus 1.6.12.

— Ortomala Lokni
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.