Issue

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.

Release Notes

No. of Comments

Resolution

Won't Do