Uso excessivo de CPU com vlock como tmux lock-command

Question

Estou executando o tmux, configurado para bloquear minhas sessões via /etc/tmux.conf:

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

(O objetivo é substituir o GNU screen - para ver se ele se comporta melhor com os vários emuladores de terminal que eu uso - que tem idle 300 lockscreen em sua configuração.)

De vez em quando, se eu permitir que uma sessão seja bloqueada e deixada por alguns dias, posso voltar à sessão para descobrir que vlock está consumindo a maior parte da minha CPU ( top mostra %CPU em 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

Enquanto isso acontece, um grande número de entradas de log ocorrem em / var / log / secure e /var/log/audit/audit.log - uma ou duas a cada segundo, por exemplo:

==> /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"

Nenhum dos consoles tty parece estar bloqueado - todos parecem desconectados. O processo tmux parece ser o proprietário do processo vlock (pelo menos, de acordo com 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

Eu acho que o ? sugere que tanto o tmux quanto o vlock se "divorciaram" de alguma forma de seus respectivos terminais, mas eu não sei como resolver, com falta de kill -9 19002 .

Eu também acho que as entradas audit.log significam uma exceção SELinux perdida, mas isso só parece acontecer depois de alguns dias de execução do vlock, onde eu teria pensado que haveria um problema sempre acontecer.

Mais uma vez, eu acho que as mensagens pam_succeed_if em segurança sugerem que alguma coisa está tentando validar o nome de usuário / senha e falhando porque o UID do root é menor que 1000, mas não consigo encontrar o processo fazendo isso. Além disso, não tenho usuários com UID > = 1000, porque ainda não defini outros usuários. Novamente, eu esperaria que isso fosse um problema o tempo todo, em vez de apenas alguns dias.

Se eu me conectar via SSH e permitir que o tmux reconecte ou mescle as sessões ( tmux new-session -t $USER ), eu posso ver a mesma sessão de antes; se essa sessão ficar ociosa por 5 minutos, poderei usar outra sessão SSH para ver a segunda instância de vlock , dessa vez pertencente a tmux e 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

Versões pertinentes em que posso pensar:

• / etc / redhat-release: CentOS Linux release 7.3.1611 (Core)
• uname -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

Não estou ligado a vlock se existir uma alternativa mais adequada em Base ou EPEL. Se não, acho que vou tentar definir lock-command para tmux detach-client para forçar uma desconexão em vez de um bloqueio, mas gostei do paradigma de bloqueio.

O que mais eu posso ver para evitar esse problema de espera? Por suas falhas percebidas, o GNU Screen nunca pareceu usar recursos como este ...

Atualização 1

OK, posso recriar de forma confiável isso agora:

1. Faça login no servidor via SSH
2. Crie / anexe a sessão tmux (eu faço isso no meu script de login, FWIW)
3. Permitir que a sessão fique inativa e comece a bloquear
4. Mate o cliente SSH em minha estação de trabalho (isto é, um desligamento não limpo do meu cliente)
5. vlock começará a girar

Suponho que posso contorná-lo usando o seguinte em um script, que eu executo usando uma tarefa do cron por minuto:

ps -ef                            \
| grep -F '/usr/bin/vlock'        \
| grep -Fv 'grep'                 \
| awk '$6 == "?" { print $2 }'    \
| xargs -r kill -9

... mas isso parece um pouco complicado.

Melhores sugestões são bem-vindas.