vlock を tmux ロックコマンドとして使用する場合の高い CPU 使用率

/etc/tmux.confを介してセッションをロックするように設定されたtmuxを実行しています。

set-option -g lock-command "/usr/bin/vlock -c"
set-option -g lock-after-time 300

（意図は、GNUを置き換えて、screen私が使用しているさまざまな端末エミュレータでより良いパフォーマンスを発揮することを確認することです。GNUはidle 300 lockscreen設定に含まれています。）

時々セッションをロックし、数日間そのままにしておくと、セッションに戻ってセッションがvlock私のCPUを大部分消費していることを確認できます（96-98とtop表示）。%CPU

  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プロセスの所有者のようです。vlockps

# 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セキュリティメッセージは次のとおりです。何ユーザー名/パスワードを確認しようとしましたが、ルートのUIDが1000未満であるため失敗しましたが、これを実行するプロセスが見つかりませんでした。また、まだ他のユーザーを設定していないため、UIDが1000を超えるユーザーはありません。もう一度言いますが、これは数日後に現れるのではなく、問題が続くと予想されます。

SSHを介して接続し、tmuxがセッションを再接続またはマージできるようにした場合（tmux new-session -t $USER）、以前と同じセッションを表示できます。セッションが5分間アイドル状態の場合は、別のSSHセッションを使用して2番目のインスタンスを表示できます。vlock、そして：tmuxsshd

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

...しかし、少しハッキングのように感じます。

より良い提案を歓迎します。