我正在运行 tmux，配置为通过 /etc/tmux.conf 锁定我的会话：
set-option -g lock-command "/usr/bin/vlock -c"
set-option -g lock-after-time 300
（目的是取代 GNU——screen看看它在我使用的各种终端模拟器中是否表现得更好——它idle 300 lockscreen的配置中有。）
时不时地，如果我允许会话锁定并将其保留几天，我可以返回该会话，发现它vlock正在消耗我的大部分 CPU（top显示%CPU为 96-98）：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19002 root 20 0 48176 8888 1040 R 98.7 1.8 13:00.60 vlock
发生这种情况时，/var/log/secure 和 /var/log/audit/audit.log 中都会出现大量日志条目——每秒一到两个，例如：
==> /var/log/audit/audit.log <==
type=USER_AUTH msg=audit(1502738594.043:4705): pid=19002 uid=0 auid=0 ses=14 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/bin/vlock" hostname=? addr=? terminal=pts/0 res=failed'
==> /var/log/secure <==
Aug 14 20:23:14 hostname.local vlock[19002]: pam_unix(vlock:auth): auth could not identify password for [root]
Aug 14 20:23:14 hostname.local vlock[19002]: pam_succeed_if(vlock:auth): requirement "uid >= 1000" not met by user "root"
所有 tty 控制台似乎都没有被锁定——它们都显示为已注销。该tmux进程似乎是该进程的所有者vlock（至少根据ps）：
# ps -ef | grep vlock
root 19002 4102 0 Aug09 ? 00:21:35 /usr/bin/vlock -c
root 25318 24147 0 20:41 pts/7 00:00:00 grep --color=auto vlock
# ps -ef | grep 4102
root 4102 1 0 Aug02 ? 00:00:00 tmux new-session -t root
root 19002 4102 0 Aug09 ? 00:22:25 /usr/bin/vlock -c
我猜这?表明 tmux 和 vlock 都以某种方式与各自的终端“分离”，但我不知道如何解决，缺少kill -9 19002.
我还猜测audit.log条目意味着缺少SELinux异常，但这似乎只在vlock运行几天后发生，我原以为会出现问题总是发生。
再次，我猜pam_succeed_if安全中的消息表明某物正在尝试验证用户名/密码并失败，因为 root 的 UID 小于 1000，但我找不到执行此操作的进程。另外，我没有UID >= 1000的用户，因为我还没有设置其他用户。再说一遍，我预计这将一直是一个问题，而不是几天后才出现。
如果我通过 SSH 连接并允许 tmux 重新附加或合并会话 ( tmux new-session -t $USER)，我可以看到与以前相同的会话；如果该会话空闲 5 分钟，我可以使用另一个 SSH 会话来查看 的第二个实例vlock，这次由tmux、 和拥有sshd：
root 26751 22688 0 21:02 pts/4 00:00:00 /usr/bin/vlock -c
root 22688 22681 0 20:22 pts/4 00:00:00 tmux new-session -t root
root 22681 838 0 20:22 ? 00:00:00 sshd: root@pts/4
root 838 1 0 Aug02 ? 00:00:00 /usr/sbin/sshd -D
我能想到的相关版本：
- /etc/redhat-release：
CentOS Linux release 7.3.1611 (Core) - 名称-a：
Linux server.local 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux - tmux-V：
tmux 1.8 - vlock -v：
1.15.5
我不介意vlockBase 或 EPEL 中是否存在更合适的替代方案。如果没有，我想我会尝试设置lock-command为tmux detach-client强制断开连接而不是锁定，但我确实喜欢锁定范例。
我还可以采取什么措施来防止出现这种旋转等待问题？由于其明显的缺陷，GNU Screen 似乎从未像这样占用资源......
更新#1
好的，我现在可以可靠地重新创建它：
- 通过 SSH 登录服务器
- 创建/附加
tmux会话（我在登录脚本中执行此操作，FWIW） - 允许该会话空闲并开始锁定
- 杀死我的工作站上的 SSH 客户端（即不干净地关闭我的客户端）
vlock将开始旋转
我想我可以使用脚本中的以下内容来解决这个问题，我使用每分钟的 cron 作业执行该脚本：
ps -ef \
| grep -F '/usr/bin/vlock' \
| grep -Fv 'grep' \
| awk '$6 == "?" { print $2 }' \
| xargs -r kill -9
...但这感觉有点像黑客。
欢迎提出更好的建议。
答案1
我也能够重现。通过 SSH 进入盒子，vlock，终止 SSH，保持 vlock 开启。过了一会儿，我们得到了这个...
cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"
