在我的其中一台服务器上，我注意到 SSH 登录确实存在延迟。
使用 ssh -vvv 选项连接时延迟发生在debug1: Entering interactive session.
连接摘录：
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
使用概述的方法这里我生成了 strace 输出并注意到该行14:09:53.676004 ppoll([{fd=5, events=POLLIN}], 1, {24, 999645000}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 0}) <25.020764>花费了 25 秒。
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>
我注意到相关时间的身份验证日志中有一个条目：
Jul 21 14:10:18 click sshd[8165]: pam_systemd(sshd:session): Failed to create session: Activation of org.freedesktop.login1 timed out
对此了解不够，它试图轮询什么，以及为什么现在在这个特定的服务器上花费 25 秒。
命令journalctl -u systemd-logind显示
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.
发出命令systemctl restart systemd-logind.service即可修复此问题（目前可能如此）。
它提到了什么Activation of org.freedesktop.login1？有没有办法可以避免以后必须重新启动 logind？我预计随着时间的推移，我管理的其他服务器也会遇到这个问题。
刚刚注意到这开始在另一台服务器上发生。
$ 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.
编辑-扩展journalctl输出。
EDIT2-当注意到这在另一台服务器上启动时，按照评论中的建议添加了 systemd-logind 状态。
更新 - 这开始发生在我的其余 Jessie 服务器上。只有我一个人遇到这种情况吗？除了重新启动 systemd-logind 之外，肯定还有其他解决方法，有人有什么想法吗？
有一个关于此问题的 Debian 错误报告770135。
答案1
当 dbus 重新启动但 systemd-logind 未重新启动时，会发生这种情况。只需执行以下操作：
systemctl restart systemd-logind
解决方案来自这里： https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/
答案2
使用：
systemctl restart systemd-logind
只能暂时解决问题。
一种解决方法是.scope从 cron 作业中删除所有文件，如下所述这里。
* 2,14 * * * root /bin/rm -f /run/systemd/system/*.scope
相关的 systemd 错误报告在这里：范围单元泄漏减慢“systemctl list-unit-files”速度并延迟登录。
看来这实际上是一个 dbus 错误：unix fd 飞行中计数中断即已在 dbus 版本 1.11.10 中解决
要永久修复此错误，您只需等待此版本的 dbus 出现在您的发行版中。目前，Debian Stretch 的 dbus 版本为 1.10.18，Ubuntu 17.04 (Zesty) 的 dbus 版本为 1.10.10，CentOS 7 的 dbus 版本为 1.6.12。