Bug 158714 - 'service vsftpd start' says OK even if exit status of vsftpd binary is 1, and does not pass on errors from that binary
'service vsftpd start' says OK even if exit status of vsftpd binary is 1, and...
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vsftpd (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-24 22:56 EDT by Mike MacCana
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-06-30 04:23:07 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)

  None (edit)
Description Mike MacCana 2005-05-24 22:56:35 EDT
Description of problem:
'service vsftpd start' says OK even if exit status of vsftpd binary is 1, and
does not pass on errors from that binary

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

How reproducible:
Always

Steps to Reproduce:
1.Put an incorrect option in /etc/vsftpd/vsftpd.conf - for example
'pretendoption'
2.'service vsftpd restart'
3.'service vsftpd status'
  
Actual results:
Starting vsftpd: OK
vsftpd dead but subsys locked

(running the actual vsftpd binary, however, fails with an exit status of 1 and
says '500 OOPS: missing value in config file for: pretendoption')

Expected results:
A failed message, and the actual error message the binary gives.
Better yet, a 'service vsftpd checkconf' like httpd and named have, and smb will
soon have (though I understand that's a larger task).
Comment 1 Mike MacCana 2005-05-24 23:50:54 EDT
I'm pretty sure:

                        echo -n $"Starting $prog for $site: "
                        /usr/sbin/vsftpd $i &
                        RETVAL=$?

will gives the RETVAL of the echo command in most cases. Try it on the command line:

# echo
# vsftpd /etc/vsftpd/vsftpd.conf & echo $?
[1] 5014
0
500 OOPS: missing value in config file for: pretendoption

[1]+  Exit 1                  vsftpd /etc/vsftpd/vsftpd.conf
Comment 2 Radek Vokal 2005-05-25 05:00:28 EDT
True, it doesn't get the return value from forked proces. I wonder why this
script is not working with daemon command ... will try to figure it out. 
Comment 3 Radek Vokal 2005-06-30 04:23:07 EDT
Fix applied on rawhide (vsftpd-2.0.3-6). This changes default behavior of vsftpd
as it has to be started in background to get the proper return value. 
Comment 4 Milan Kerslager 2006-04-21 06:26:10 EDT
This bug has been reported in the bug #164998 too (which is CLOSED RAWHIDE
because another bug report). Looking for the RHEL4 U3.
Comment 5 Radek Vokal 2006-04-21 06:46:23 EDT
Sorry, it's closed as NEXTRELEASE, so it won't hit RHEL4 but it's planned for RHEL5.
Comment 6 Milan Kerslager 2006-04-21 08:21:45 EDT
Is it possible to use daemon() function to get proper RETCODE without changing
default behaviour of vsftpd binary itself?
Comment 7 Radek Vokal 2006-04-21 08:33:53 EDT
Yes, in vsftpd.conf set background=YES. Now you can use daemon() and get the
RETCODE. 
Comment 8 Milan Kerslager 2006-04-21 08:46:55 EDT
I see the need to change config file and thus NEXTRELEASE.

You may fix init script by using shell commands:

...
/usr/sbin/vsftpd $i &
PID=$!
sleep 1s
[ -d /proc/$PID ] && success $"$prog $site" || failure $"$prog $site"
...

This is a really bug to report [OK] even vsftpd daemon does not start at all.
Comment 9 Radek Vokal 2006-04-24 03:49:20 EDT
Well, you can't be sure that one second is enough and introducing unnecessary
delay is not very nice solution. Anyway, I'll discuss it with other developers
and our quality team, if they have any opinion about this. 
Comment 10 Milan Kerslager 2006-04-24 04:00:04 EDT
You are right. This is only "not always broken" solution... But IIRC similar
workaround has been used in another package too.

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