Uwaga: Zaczęło się to od samouczka „Jak debugować”, ale ostatecznie stało się rozwiązaniem, które pomogło mi na serwerze LTS Ubuntu 16.04.
TLDR : Uruchom landscape-sysinfoi sprawdź, czy wykonanie polecenia zajmuje dużo czasu; to wydruk informacji o systemie przy nowym logowaniu SSH. Zauważ, że to polecenie nie jest dostępne we wszystkich systemach, landscape-commonpakiet je instaluje. („Ale czekaj, jest więcej ...”)
Uruchom drugi serwer ssh na innym porcie komputera, na którym występuje problem, zrób to w trybie debugowania, który nie rozwinie go i wydrukuje komunikaty debugowania:
sudo /usr/sbin/sshd -ddd -p 44321
połącz się z tym serwerem z innego komputera w trybie pełnym:
ssh -vvv -p 44321 username@server
Mój klient wyświetla następujące wiersze tuż przed snem:
debug1: Entering interactive session.
debug1: pledge: network
Googlowanie, które nie jest tak naprawdę pomocne, ale logi serwera są lepsze:
debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051
Zauważyłem, że po przejściu UsePAM yesna UsePAM noten problem został rozwiązany.
Niepowiązane UseDNSani żadne inne ustawienie, UsePAMwpływa tylko na ten problem w moim systemie.
Nie mam pojęcia dlaczego, a ja też nie pozostawiając UsePAMna no, ponieważ nie wiem, których skutki uboczne są, ale to pozwala mi kontynuować śledztwo.
Więc proszę, nie uważaj tego za odpowiedź, ale za pierwszy krok, aby dowiedzieć się, co jest nie tak.
Więc kontynuowałem badanie i uruchomiłem sshdz strace( sudo strace /usr/sbin/sshd -ddd -p 44321). To dało następujące:
sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5) = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022) = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385
Linia /etc/update-motd.dwzbudziła we mnie podejrzenia, najwyraźniej proces czeka na wynik tego, co jest w środku/etc/update-motd.d
Więc cdbyłyby do /etc/update-motd.di prowadził sudo chmod -x *w celu zahamowania PAM uruchomić wszystkie pliki, które generują ten dynamiczny Message Of The Day, który obejmuje obciążenie systemu i jeśli pakiety muszą zostać zmodernizowane, i to rozwiązało problem.
Jest to serwer oparty na „energooszczędnym” procesorze N3150, który ma dużo pracy do wykonania 24 godziny na dobę, 7 dni w tygodniu, więc myślę, że zebranie wszystkich tych danych motd było dla niego po prostu za dużo.
Mogę zacząć włączać skrypty w tym folderze selektywnie, aby zobaczyć, które są mniej szkodliwe, ale specjalne wywoływanie landscape-sysinfojest bardzo wolne i 50-landscape-sysinfowywołuje to polecenie. Myślę, że właśnie to powoduje największe opóźnienie.
Po ponownym uaktywnieniem większość plików doszedłem do wniosku, że
50-landscape-sysinfoi 99-esmbyły przyczyną moich kłopotów. 50-landscape-sysinfowykonanie zajęło około 5 sekund i 99-esmokoło 3 sekund. Wszystkie pozostałe pliki łącznie około 2 sekund.
Ani 50-landscape-sysinfoi nie 99-esmsą kluczowe. 50-landscape-sysinfodrukuje ciekawe statystyki systemowe (a także jeśli masz mało miejsca!) i 99-esmdrukuje wiadomości związane zUbuntu Extended Security Maintenance
Wreszcie możesz utworzyć skrypt za pomocą echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shi uzyskać ten wydruk na żądanie.