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 158714 - 'service vsftpd start' says OK even if exit status of vsftpd binary is 1, and does not pass on errors from that binary
Summary: 'service vsftpd start' says OK even if exit status of vsftpd binary is 1, and...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vsftpd
Version: 4.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Radek Vokal
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-25 02:56 UTC by Mike MacCana
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-30 08:23:07 UTC


Attachments (Terms of Use)

Description Mike MacCana 2005-05-25 02:56:35 UTC
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-25 03:50:54 UTC
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 09:00:28 UTC
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 08:23:07 UTC
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 10:26:10 UTC
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 10:46:23 UTC
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 12:21:45 UTC
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 12:33:53 UTC
Yes, in vsftpd.conf set background=YES. Now you can use daemon() and get the
RETCODE. 

Comment 8 Milan Kerslager 2006-04-21 12:46:55 UTC
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 07:49:20 UTC
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 08:00:04 UTC
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.