Bug 236707

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.

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 $?
0

Therefore the initscript still can't know vsftpd failed.

(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
error.

(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.

(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.

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.

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.

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
[FAILED]

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 */
     vsf_sysutil_close_failok(0);

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?

~~ 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.

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