☰

使用 vlock 作为 tmux 锁定命令时 CPU 使用率过高

tag-icon • tag-icon tmux cpu-usage
使用 vlock 作为 tmux 锁定命令时 CPU 使用率过高

我正在运行 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

好的，我现在可以可靠地重新创建它：

  1. 通过 SSH 登录服务器
  2. 创建/附加tmux会话（我在登录脚本中执行此操作，FWIW）
  3. 允许该会话空闲并开始锁定
  4. 杀死我的工作站上的 SSH 客户端（即不干净地关闭我的客户端）
  5. 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/"

在此输入图像描述

相关内容