Bug 185635 - "service vsftpd stop" not stopping all vsftpd processes
"service vsftpd stop" not stopping all vsftpd processes
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: vsftpd (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Nagy
bzcl34nup
: Reopened, Triaged
Depends On: 456914
Blocks: 441485
  Show dependency treegraph
 
Reported: 2006-03-16 11:00 EST by Erik Terwan
Modified: 2016-07-26 19:46 EDT (History)
9 users (show)

See Also:
Fixed In Version: 2.0.6-3.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 00:51:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patched /etc/init.d/functions (10.18 KB, text/plain)
2006-03-16 11:00 EST, Erik Terwan
no flags Details
Patch for vsftpd (4.29 KB, patch)
2008-05-02 08:40 EDT, Martin Nagy
no flags Details | Diff

  None (edit)
Description Erik Terwan 2006-03-16 11:00:28 EST
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
Comment 1 Erik Terwan 2006-03-16 11:00:28 EST
Created attachment 126227 [details]
Patched /etc/init.d/functions
Comment 2 Radek Vokal 2006-03-16 12:50:26 EST
Proposed change belongs to initscripts. Reassigning .. 
Comment 3 Bill Nottingham 2006-03-16 14:50:38 EST
That's... not clean.

There needs to be a more generic way to do this.
Comment 4 Miloslav Trmač 2006-11-11 18:32:03 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.
Comment 5 R P Herrold 2007-09-14 09:12:08 EDT
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?
Comment 6 Maros Barabas 2007-09-27 07:46:26 EDT
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
Comment 8 Bug Zapper 2008-04-03 13:08:18 EDT
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.
Comment 9 R P Herrold 2008-04-03 13:35:23 EDT
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.
Comment 10 Martin Nagy 2008-04-04 05:39:07 EDT
Yes you do, this bug is filed against fedora and has nothing to do with Red Hat
Enterprise Linux.
Comment 11 Martin Nagy 2008-04-08 03:59:22 EDT
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.
Comment 12 Martin Nagy 2008-04-25 10:17:34 EDT
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.
Comment 13 Martin Nagy 2008-05-02 08:40:52 EDT
Created attachment 304379 [details]
Patch for vsftpd

This should help, it installs a signal handler for SIGTERM which kills all
children. Please test. Thanks.
Comment 14 Bug Zapper 2008-05-13 22:07:00 EDT
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
Comment 15 Martin Nagy 2008-09-22 08:21:45 EDT
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.
Comment 16 Bug Zapper 2008-11-25 20:48:44 EST
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
Comment 17 Bug Zapper 2009-11-18 03:06:08 EST
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
Comment 18 Bug Zapper 2009-12-18 00:51:40 EST
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.

Note You need to log in before you can comment on or make changes to this bug.