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
Created attachment 126227 [details] Patched /etc/init.d/functions
Proposed change belongs to initscripts. Reassigning ..
That's... not clean. There needs to be a more generic way to do this.
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.
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?
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
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.
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.
Yes you do, this bug is filed against fedora and has nothing to do with Red Hat Enterprise Linux.
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.
It seems that I haven't tested the bug enough. When I log in using anonymous and with a regular user name and then execute "service vsftpd stop", the regular user vsftpd process will die, but the anonymous one will still run.
Created attachment 304379 [details] Patch for vsftpd This should help, it installs a signal handler for SIGTERM which kills all children. Please test. Thanks.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
OK, the problem with this patch is that we use vsf_sysutil_install_sighandler() but we really should use vsf_sysutil_install_async_sighandler() and additionally make sure we unblock the signal in vsf_sysutil_accept_timeout() and after that block it again. Fixing this bug will be a pretty radical change, since administrators that are used to reloading with 'service vsftpd restart' will now find that vsftpd children are killed and standing connections (and hence possibly file transfers) are severed. I'm adding Bug #456914 as a dependency, since we will need alternate way of reloading the configuration ('service vsftpd reload'). This should be ideally addressed in Fedora 11.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.