Bug 441485 - "service vsftpd stop" not stopping all vsftpd processes
"service vsftpd stop" not stopping all vsftpd processes
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vsftpd (Show other bugs)
5.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Jiri Skala
: Reopened
Depends On: 185635
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-08 08:42 EDT by R P Herrold
Modified: 2014-11-09 17:31 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:39:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
The patch ensures stopping all child processes (3.99 KB, patch)
2009-03-19 04:05 EDT, Jiri Skala
no flags Details | Diff

  None (edit)
Description R P Herrold 2008-04-08 08:42:55 EDT
+++ 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@pkn-vriescheloo.nl on 2006-03-16 11:00 EST --
Created an attachment (id=126227)
Patched /etc/init.d/functions


-- Additional comment from rvokal@redhat.com on 2006-03-16 12:50 EST --
Proposed change belongs to initscripts. Reassigning .. 

-- Additional comment from notting@redhat.com 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@redhat.com 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@owlriver.com 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@redhat.com 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@redhat.com 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@owlriver.com 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@redhat.com 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@redhat.com 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.
Comment 1 Martin Nagy 2008-04-25 08:13:50 EDT
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.
Comment 3 RHEL Product and Program Management 2008-07-21 19:03:52 EDT
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 "?".
Comment 4 Daniel Riek 2008-08-19 17:31:24 EDT
Proposing for FasTrack.
Comment 8 Martin Nagy 2008-09-22 08:27:20 EDT
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.
Comment 9 R P Herrold 2008-12-08 09:37:15 EST
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
Comment 11 RHEL Product and Program Management 2009-03-09 10:34:44 EDT
Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request.
Comment 13 Jiri Skala 2009-03-19 04:05:19 EDT
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.
Comment 17 errata-xmlrpc 2009-09-02 05:39:39 EDT
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

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