Note: Ceci a commencé comme un tutoriel "Comment déboguer", mais a fini par être la solution qui m'a aidé sur un serveur Ubuntu 16.04 LTS.
TLDR : Exécuter landscape-sysinfoet vérifier si cette commande prend beaucoup de temps pour se terminer; c'est l'impression des informations système sur une nouvelle connexion SSH. Notez que cette commande n'est pas disponible sur tous les systèmes, le landscape-commonpackage l'installe. ("Mais attendez, il y a plus ...")
Démarrez un deuxième serveur ssh sur un autre port de la machine qui a le problème, faites-le en mode débogage, ce qui ne le fera pas changer et affichera les messages de débogage:
sudo /usr/sbin/sshd -ddd -p 44321
connectez-vous à ce serveur à partir d'une autre machine en mode prolixe:
ssh -vvv -p 44321 username@server
Mon client affiche les lignes suivantes juste avant de commencer à dormir:
debug1: Entering interactive session.
debug1: pledge: network
Googler ce n'est pas vraiment utile, mais les journaux du serveur sont meilleurs:
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
J'ai remarqué que lorsque je change UsePAM yesd' UsePAM noalors ce problème est résolu.
Non lié à UseDNSou à tout autre paramètre, UsePAMaffecte uniquement ce problème sur mon système.
Je n'ai pas la moindre idée pourquoi, et je suis pas non plus laisser UsePAMà no, parce que je ne sais pas que les effets secondaires sont, mais cela me permet de continuer à enquêter.
Alors, s'il vous plaît, ne considérez pas cela comme une réponse, mais comme une première étape pour commencer à découvrir ce qui ne va pas.
J'ai donc continué à enquêter et j'ai couru sshdavec strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Cela a donné ce qui suit:
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
La ligne /etc/update-motd.dm'a rendu méfiant, apparemment le processus attend le résultat de la chose qui est dans/etc/update-motd.d
Donc , je cd« d en /etc/update-motd.det a couru un sudo chmod -x *pour inhiber PAM pour exécuter tous les fichiers qui génèrent cette dynamique Message Of The Day, qui comprend la charge du système et si les paquets doivent être mis à jour, et ce résolu la question.
Ceci est un serveur basé sur un processeur N3150 "économe en énergie" qui a beaucoup de travail à faire 24h / 24, donc je pense que la collecte de toutes ces données motd était trop pour elle.
Je peux commencer à activer les scripts de ce dossier de manière sélective, afin de voir ceux qui sont moins nocifs, mais appeler spécialement landscape-sysinfoest très lent et 50-landscape-sysinfoappelle cette commande. Je pense que c'est celui qui cause le plus gros retard.
Après la plupart des réactivation des fichiers que je suis venu à la conclusion que
50-landscape-sysinfoet 99-esmétaient la cause de mes ennuis. 50-landscape-sysinfoa pris environ 5 secondes pour exécuter et 99-esmenviron 3 secondes. Tous les fichiers restants environ 2 secondes au total.
Ni 50-landscape-sysinfoet 99-esmsont cruciaux. 50-landscape-sysinfoaffiche des statistiques système intéressantes (et aussi si vous manquez d'espace!) et 99-esmaffiche des messages relatifs àUbuntu Extended Security Maintenance
Enfin, vous pouvez créer un script avec echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shet obtenir cette impression sur demande.