Excessive CPU usage with vlock as tmux lock-command

I am running tmux, configured to lock my sessions via /etc/tmux.conf:

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

(The aim is to replace GNU screen -- to see if it behaves better with the various terminal emulators I use -- which has idle 300 lockscreen in its config.)

Every now and again, if I allow a session to lock and leave it for a few days, I can return to the session to find that vlock is consuming most of my CPU (top shows %CPU at 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

While this is happening, a large number of log entries occur in both /var/log/secure and /var/log/audit/audit.log -- one or two every second, e.g.:

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

None of the tty consoles appear to be locked -- they all appear logged out. The tmux process appears to be the owner of the vlock process (at least, according to 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

I guess the ? suggests that both tmux and vlock have 'divorced' themselves somehow from their respective terminals, but I don't know how to resolve, short of kill -9 19002.

I also guess that the audit.log entries mean a missing SELinux exception, but this only seems to happen after a few days of vlock running, where I'd have thought a problem there would always happen.

Again, I guess the pam_succeed_if messages in secure suggest that something is attempting to validate username/password and failing because the UID of root is less than 1000, but I can't find the process doing that. Besides, I have no users with UID >= 1000, because I haven't set other users up yet. Again, I would expect this to be a problem all the time, rather than just after a few days.

If I connect via SSH and allow tmux to either reattach or merge sessions (tmux new-session -t $USER), I can see the same session as before; if that session then idles for 5 mins, I can use another SSH session to see the second instance of vlock, this time owned by tmux, and 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

Pertinent versions, that I can think of:

• /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

I'm not wedded to vlock if a more-suitable alternative exists in Base or EPEL. If not, I guess I'll try setting lock-command to tmux detach-client to force a disconnection rather than a lock, but I did like the locking paradigm.

What else can I look at to prevent this spin-wait problem? For its perceived faults, GNU Screen never seemed to take up resources like this...

Update #1

OK, I can reliably recreate this now:

1. Login to the server via SSH
2. Create/attach the tmux session (I do this in my login script, FWIW)
3. Allow that session to idle and start locking
4. Kill the SSH client on my workstation (i.e. an unclean shutdown of my client)
5. vlock will start spinning

I suppose I can get around it using the following in a script, which I execute using a per-minute cron job:

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

...but that feels like a bit of a hack.

Better suggestions are welcome.