![使用 vlock 作为 tmux 锁定命令时 CPU 使用率过高](https://linux22.com/image/116139/%E4%BD%BF%E7%94%A8%20vlock%20%E4%BD%9C%E4%B8%BA%20tmux%20%E9%94%81%E5%AE%9A%E5%91%BD%E4%BB%A4%E6%97%B6%20CPU%20%E4%BD%BF%E7%94%A8%E7%8E%87%E8%BF%87%E9%AB%98.png)
我正在运行 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
我不介意vlock
Base 或 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
...但这感觉有点像黑客。
欢迎提出更好的建议。