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 세션을 사용하여 두 번째 인스턴스를 볼 수 있습니다 .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

...하지만 약간 해킹처럼 느껴집니다.

더 나은 제안을 환영합니다.