Description of problem:
I tried to clone Bug #1688848, that did not work:

vsftpd sessions enabled causes continual growth of utmp and high system cpu% 



Cloning justification: See Red Hat support case: https://access.redhat.com/support/cases/#/case/02896756

Hi, We are cloning that BZ because it seems we have similar issue on RHEL8.2, with slightly different symptoms:


-We do have session_support in the vsftpd configuration:
sudo less /etc/vsftpd/vsftpd.conf | grep session
# You may change the default value for timing out an idle session.
...
session_support=YES



-We do have rather massive /run/utmp:
sudo du -sh /run/utmp 
292M	/run/utmp



-We do have impact on CPU, quoting from our Red Hat support case:
The root cause for the CPU consumption for sshd is definitely having a large /run/utmp database on the system.
Checking the strace again, we can see that all the entries except a few are "vsftpd" entries (105683 over 105690)
We have some monitoring screenshot illustrating the cpu impact.



-We did a utmpdump and confirmed the above, it's vsftpd the culprit:

utmpdump /run/utmp 
[8] [92690] [    ] [        ] [vsftpd:92690] [                    ] [0.0.0.0        ] [1970-01-01T00:00:00,000000+00:00]
[8] [92725] [    ] [        ] [vsftpd:92725] [                    ] [0.0.0.0        ] [1970-01-01T00:00:00,000000+00:00]
[8] [92788] [    ] [        ] [vsftpd:92788] [                    ] [0.0.0.0        ] [1970-01-01T00:00:00,000000+00:00]
[8] [92796] [    ] [        ] [vsftpd:92796] [                    ] [0.0.0.0        ] [1970-01-01T00:00:00,000000+00:00]
[8] [92812] [    ] [        ] [vsftpd:92812] [                    ] [0.0.0.0        ] [1970-01-01T00:00:00,000000+00:00]
[8] [92844] [    ] [        ] [vsftpd:92844] [                    ] [0.0.0.0        ] [1970-01-01T00:00:00,000000+00:00]
... (thousands and thousands of similar lines; see the incorrect timestamp also)


-At the time of the issue, "who" command is barely responding (due to the size of /run/utmp)

- We do not have the same "gone - no logout" with the last command:
From the server (RHEL8):
last -f /var/run/utmp
user1 vsftpd:33661 10.3.20.96       Wed Mar 24 14:41   still logged in
user2 vsftpd:33651 10.3.20.93       Wed Mar 24 14:40   still logged in
user2 vsftpd:33632 10.3.20.94       Wed Mar 24 14:38   still logged in
user3 vsftpd:33632 10.3.20.94       Wed Mar 24 14:38   still logged in
user2 vsftpd:33558 10.3.20.93       Wed Mar 24 14:28   still logged in
user3 vsftpd:33430 47.x.y.z     Wed Mar 24 14:11   still logged in
user1 vsftpd:33632 10.3.20.93       Wed Mar 24 14:38   still logged in
user4 vsftpd:33634 10.3.221.20      Wed Mar 24 14:39   still logged in
adminuser   pts/0        178.x.y.z   Wed Mar 24 14:41   still logged in
reboot   system boot  4.18.0-193.41.1. Tue Mar  2 19:16   still running

utmp begins Tue Mar  2 19:16:24 2021
[qa/DMZ] adminuser@hostname:~$ date
Wed 24 Mar 14:41:46 UTC 2021


We have seen an ERRATA was published, not available for RHEL8:

https://access.redhat.com/errata/RHBA-2020:1010


Version-Release number of selected component (if applicable):

vsftpd.x86_64                                                   3.0.3-31.el8



How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
/run/utmp is very big and impact cpu

Expected results:
/run/utmp should not be soo big and/or impacting performances

Additional info:

Customer had to restart the server, so that /run/utmp gets to a reasonnable size, then it seems to progressively grow up and consumme more cpu.