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

1. 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.