Red Hat Bugzilla – 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
Last modified: 2007-11-30 17:07:18 EST
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):
Steps to Reproduce:
1.Put an incorrect option in /etc/vsftpd/vsftpd.conf - for example
2.'service vsftpd restart'
3.'service vsftpd status'
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')
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).
I'm pretty sure:
echo -n $"Starting $prog for $site: "
/usr/sbin/vsftpd $i &
will gives the RETVAL of the echo command in most cases. Try it on the command line:
# vsftpd /etc/vsftpd/vsftpd.conf & echo $?
500 OOPS: missing value in config file for: pretendoption
+ Exit 1 vsftpd /etc/vsftpd/vsftpd.conf
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.
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.
This bug has been reported in the bug #164998 too (which is CLOSED RAWHIDE
because another bug report). Looking for the RHEL4 U3.
Sorry, it's closed as NEXTRELEASE, so it won't hit RHEL4 but it's planned for RHEL5.
Is it possible to use daemon() function to get proper RETCODE without changing
default behaviour of vsftpd binary itself?
Yes, in vsftpd.conf set background=YES. Now you can use daemon() and get the
I see the need to change config file and thus NEXTRELEASE.
You may fix init script by using shell commands:
/usr/sbin/vsftpd $i &
[ -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.
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.
You are right. This is only "not always broken" solution... But IIRC similar
workaround has been used in another package too.