Connexion ssh lente - L'activation de org.freedesktop.login1 a expiré
Sur l'un de mes serveurs, j'ai remarqué un réel retard sur les connexions SSH.
En se connectant à l'aide des options ssh -vvv, le retard se produit à debug1: Entering interactive session.
extrait de connexion:
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 [email protected]
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
en utilisant la méthode décrite ici J'ai généré une sortie strace et j'ai remarqué la ligne 14:09:53.676004 ppoll([{fd=5, events=POLLIN}], 1, {24, 999645000}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 0}) <25.020764> qui prend 25 secondes.
extrait de sortie 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>
J'ai remarqué une entrée dans les journaux d'authentification au moment pertinent:
Jul 21 14:10:18 click sshd[8165]: pam_systemd(sshd:session): Failed to create session: Activation of org.freedesktop.login1 timed out
Ne sachant pas assez à ce sujet, pourquoi essaie-t-il d'interroger et pourquoi prend-il maintenant 25 secondes sur ce serveur particulier?.
La commande journalctl -u systemd-logind Affiche
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.
L'émission de la commande systemctl restart systemd-logind.service Le corrige (pour l'instant probablement).
Quel est le Activation of org.freedesktop.login1 Qu'il mentionne? Existe-t-il un moyen de ne pas avoir à redémarrer la déconnexion à l'avenir? J'espère qu'avec le temps, j'aurai ce problème avec le reste des serveurs que je gère.
Je viens de remarquer que cela commence à se produire sur un autre serveur.
$ 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 - sortie journalctl développée.
EDIT2 - ajout du statut systemd-logind comme suggéré dans les commentaires lorsque cela est remarqué à partir d'un autre serveur.
MISE À JOUR - Cela commence à arriver au reste de mes serveurs Jessie. Suis-je le seul à vivre cela? Il doit y avoir un correctif autre que le redémarrage de systemd-logind, quelqu'un a-t-il des idées?
Il y a un rapport de bogue Debian à ce sujet 770135 .
Cela se produit lorsque dbus est redémarré, mais systemd-logind n'est pas redémarré. Procédez simplement comme suit:
systemctl restart systemd-logind
La solution est d'ici: https://major.io/2015/07/27/very-slow-ssh-logins-on-Fedora-22/
En utilisant:
systemctl restart systemd-logind
ne résout le problème que temporairement.
Une solution consiste à supprimer tous les .scope fichiers d'un travail cron, comme indiqué ici .
* 2,14 * * * root /bin/rm -f /run/systemd/system/*.scope
Le rapport de bogue systemd connexe est ici: Fuite d'unités de portée ralentissant "systemctl list-unit-files" et retardant les connexions .
Il semble que ce soit en fait un bogue dbus: décompte en vol unix fd cassé qui est résolu dans dbus version 1.11.10
Pour une correction permanente de ce bogue, il vous suffit d'attendre que cette version de dbus apparaisse dans votre distribution. Pour l'instant, Debian Stretch est à dbus 1.10.18, Ubuntu 17.04 (Zesty) est à 1.10.10, CentOS 7 est à dbus 1.6.12.