Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236707 - vsftpd would crash without any error messages on bind fail
Summary: vsftpd would crash without any error messages on bind fail
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: vsftpd
Version: 5.0
Hardware: powerpc
OS: Linux
Target Milestone: ---
: ---
Assignee: Jiri Skala
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-17 07:59 UTC by Yan Li
Modified: 2014-11-09 22:30 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-02 09:39:21 UTC
Target Upstream Version:

Attachments (Terms of Use)
Please try to apply this patch. Thanks. (deleted)
2007-09-17 13:52 UTC, Maros Barabas
no flags Details | Diff
Daemonizing improvement (deleted)
2009-04-17 07:24 UTC, Jiri Skala
no flags Details | Diff

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1282 normal SHIPPED_LIVE vsftpd bug fix update 2009-09-01 09:49:15 UTC

Description Yan Li 2007-04-17 07:59:01 UTC
Description of problem:
If there is another FTP server running when you tried to start 
vsftpd, the bind will fail, and vsftpd would crash, without any error 
messages, and the user will have no way to know vsftpd failed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Start another FTP server, we use GSSFTP here for testing. Edit the
"/etc/xinetd.d/gssftp", change line "disable = yes" to "disable = no".
Then Start xinetd:
# service xinetd restart

2. Try start vsftpd:
# service vsftpd start
Starting vsftpd for vsftpd:                                [  OK  ]
It said "OK", but actually vsftpd is not started.

3. Check vsftpd state:
# service vsftpd status
vsftpd dead but subsys locked

4. Try to start vsftpd manually:
# vsftpd
#### No any error messages displayed here
# echo $?
And the return value is zero, which indicates a success. But actually 
no vsftpd process is running:
# ps -ef | grep vsftpd | grep -v grep
### no running vsftpd process can be found.

Actual results:
If vsftpd failed to start, it display no error message and return 0.

Expected results:
On such kind of errors, a good vsftpd program should display this message:
# vsftpd
500 OOPS: could not bind listening IPv4 socket
And the return value should be non-zero:
# echo $?

Comment 1 Maros Barabas 2007-09-17 13:52:27 UTC
Created attachment 197441 [details]
Please try to apply this patch. Thanks. 

If you can, please test it with SSH support, if ssh hang on exit.

Comment 2 Yan Li 2008-01-17 09:41:28 UTC
Maros, thanks for your patch! We've tested it. It showed the error message "500
OOPS: could not bind listening IPv4 socket", but the RC was still "0", which
should be non-zero.

# vsftpd
500 OOPS: could not bind listening IPv4 socket
# echo $?

Therefore the initscript still can't know vsftpd failed.

Comment 3 Martin Nagy 2008-02-05 23:23:17 UTC
(In reply to comment #2)
This can't be fixed since vsftpd binds after fork. Error would only be detected
if you'd use background=NO, but then the init script would hang if there was no

Comment 4 Yan Li 2008-02-14 09:33:50 UTC
(In reply to comment #3)
Martin, I knew the situation. But the vsftpd shipped with RHEL4 returns non-zero
on binding error, thus cooperates well with init. Therefore this bug of RHEL5
should be considered a regression.

Comment 5 Martin Nagy 2008-02-14 15:59:11 UTC
(In reply to comment #4)
Yes, but this is because in RHEL4 the option 'background' defaults to NO
(although this is probably going to be changed in RHEL4.7) and in RHEL5 it
defaults to YES. And a bug is considered to be a regression only when the bug
was introduced in the updates. So, if you add 'background=NO' into your
configuration, vsftpd will return 1 on bind fail, as it will not fork into the
background before it will attempt to bind. However, if you do set it that way,
the init script will hang.

Comment 6 Yan Li 2008-08-04 10:13:32 UTC
I understood the tech difficulty to return non-zero return code for errors in child processes.

That being said, the vsftpd init script behaves against Unix conventions by returning 0 on failure. Apache2 init script is doing better on this, it returns 1 on bind failure. Perhaps the Apache parent waits before exiting until all it's children's init phase has finished and set return code accordingly.

I haven't tested the tarball from upstream so I'm not sure whether this behavior exists in upstream versions. If that's true, we can mirror this bug to upstream bug tracking system to let them do structural change.

Comment 7 Jiri Skala 2009-04-17 07:24:32 UTC
Created attachment 339965 [details]
Daemonizing improvement

This patch fixes the issue. The parent process waits for binding (or failing) forked one then exits with correct exit number.

Comment 10 Don Zickus 2009-05-05 22:37:46 UTC
Oddly this patch is giving us grief in kernel land.  We have audit testing that uses vsftpd to verify something or other which allows us to conclude that the kernel audit subsystem is working correctly.

But due to some recent vsftpd changes, our tests fail with this line

 /sbin/service vsftpd start
Starting vsftpd for vsftpd: /bin/bash: line 1: 24071 User defined signal 1   /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

Looking through the changelog we noticed this patch (which is the same attached here) vsftpd-2.0.5-daemonize_plus.patch has the following snippet:

@@ -50,7 +52,13 @@ vsf_standalone_main(void)
     if (forkret > 0)
       /* Parent, just exit */
-      vsf_sysutil_exit(0);
+      vsf_sysutil_sigaction(kVSFSysUtilSigALRM, handle_sigalrm);
+      vsf_sysutil_sigaction(kVSFSysUtilSigUSR1, handle_sigusr1);
+      vsf_sysutil_set_alarm(3);
+      vsf_sysutil_pause();
+      vsf_sysutil_exit(1);
     /* Son, close standard FDs to avoid SSH hang-on-exit */

Our thoughts are there is a race condition here.  As soon as the child is forked, there is a race to see if SIGUSR1 can be registered _before_ the child sends that signal.  In our testing, we have seen the parent lose that race, thus getting the weird User define signal 1 messages.

Any thoughts?

Comment 17 Chris Ward 2009-07-03 17:57:17 UTC
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Comment 20 errata-xmlrpc 2009-09-02 09:39:21 UTC
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.

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