+++ This bug was initially created as a clone of Bug #185635 +++ Cloning to RHEL 5, as it still persists there. Description of problem: When stopping vsftpd using "/etc/init.d/vsftpd stop" of "service vsftpd stop" only the main vsftpd process is stopped. The children (started whenever an ftp connection is made) remain active. These connection don't seem to need the mother process, so active connections remain active after the stop command is issued. Some minutes (5? 10?) later the children discover that the mother is gone and stop also. Version-Release number of selected component (if applicable): 2.0.3-1 Kernel: 2.6.15-1.1833_FC4 How reproducible: Start vsftpd, make an ftp connection and stop vsftpd. With "ps aux|grep vsftpd" you can see that there are still vsftpd processes running. A way to a solution: In /etc/init.d/functions there is a routine called killproc(). This routine finds the pids of the vsftpd processes with "pid=`pidof -c -o $$ -o $PPID -o %PPID -x $1 || pidof -c -o $$ -o $PPID -o %PPID -x $base`". The problem is that pidof doesn't find the children processes because of the -c argument. This argument skips processes with different home directories. The children are running as users ftp and nobody (which don't have the same home directories as root), so they are not discovered. Temporary patch: Replace: pid=`pidof -c -o $$ -o $PPID -o %PPID -x $1 || \ pidof -c -o $$ -o $PPID -o %PPID -x $base` with: if [ "$base" = "vsftpd" ] ; then pid=`pidof -o $$ -o $PPID -o %PPID -x $1 || \ pidof -o $$ -o $PPID -o %PPID -x $base` else pid=`pidof -c -o $$ -o $PPID -o %PPID -x $1 || \ pidof -c -o $$ -o $PPID -o %PPID -x $base` fi -- Additional comment from erik.terwan on 2006-03-16 11:00 EST -- Created an attachment (id=126227) Patched /etc/init.d/functions -- Additional comment from rvokal on 2006-03-16 12:50 EST -- Proposed change belongs to initscripts. Reassigning .. -- Additional comment from notting on 2006-03-16 14:50 EST -- That's... not clean. There needs to be a more generic way to do this. -- Additional comment from mitr on 2006-11-11 18:32 EST -- I think killing all vsftpd processes, whether launched from the init script or not, is unnecessarily crude. I'd expect that the main vsftpd process can keep track of its children and kill them when it recieves SIGTERM. vsf_standalone_main() already keeps a hash table of child processes, so adding the SIGTERM handler should be quite easy. Another SIGTERM handler would be necessary to take care of the processes created in vsf_two_process_start(). The above would be enough to close all connections on (service vsftpd stop), although it would still kill unrelated vsftpd processes run by users. Ideally, vsftpd would write a PID file (a separate one for each configured site), and (service vsftpd stop) would only use these PID files to determine which processes to terminate. -- Additional comment from herrold on 2007-09-14 09:12 EST -- I observe this is still occurring with vsftpd-2.0.5-10 in RHEL 5 ... This bug is 16 months old at this point and still not fixed. How can this be advanced and fixed? -- Additional comment from mbarabas on 2007-09-27 07:46 EST -- I can't reproduce this bug on last version on vsftpd (2.0.5-19.devel). Can you try it please and send me exact sequence of commands when it fails? Thanks -- Additional comment from fedora-triage-list on 2008-04-03 13:08 EST -- Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. -- Additional comment from herrold on 2008-04-03 13:35 EST -- I confirm that I contue to be able to, and have just repeated this bug today with the vsftpd version shipping with RHEL 5 (2.0.5-10) A child vsftpd process actively being uses, persists, and returns content after: /sbin/service vsftpd stop As such one cannot reliably shot down vsftpd with the present tools. This actually has security overtones ... in the sense that one cannot stop an in progress 'attack vector' I see that it has been touched by Fedora bug triagers, rather than #redhat handlers or the @redhat to whom it is assigned; If I need to 'clone' this bug to RHEL, rather than leave it as filed against 'All' so that it gets addressed, please let me know here. -- Additional comment from mnagy on 2008-04-04 05:39 EST -- Yes you do, this bug is filed against fedora and has nothing to do with Red Hat Enterprise Linux. -- Additional comment from mnagy on 2008-04-08 03:59 EST -- The vsftpd stop command currently works as it should and all children are killed when 'service vsftpd stop' command is issued. Closing as CURRENTRELEASE. If this issue exists in Red Hat Enterprise Linux, please clone this bug or open a new one against the correct version (4 and/or 5). Thank you.
Hmm, I just tried the newest vsftpd that is in fedora with rhel5 and the results were same as with the old one, so I guess the problem lies somewhere else, I will investigate this further.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
Proposing for FasTrack.
I had some thoughts and I think we shouldn't fix this bug. My reasoning is that we would break 'service vsftpd restart'. Currently, administrators can count on the restart as a way of reloading the configuration (with a risk that vsftpd won't start again if the configuration file isn't correct). If we would change that behaviour then we might make few people angry because their connection was severed in the middle of a file transfer, while the administrator was just trying to reload the configuration. I'd opt to only fix this in Fedora so that the fix will be in the future major release of RHEL.
We are at the threshold of the next RHEL starting its stabilization and then beta process -- if the change is to be deferred until then, NOW is the time to apply it -- Russ herrold
Quality Engineering Management has reviewed and declined this request. You may appeal this decision by reopening this request.
Created attachment 335810 [details] The patch ensures stopping all child processes The patch is backported from vsftpd-2.1.0 and works fine for me.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1282.html