Bug 28146 - RETVAL=$? isn't always reliable due to daemon()/fork()
RETVAL=$? isn't always reliable due to daemon()/fork()
Product: Red Hat Linux
Classification: Retired
Component: openssh (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Depends On:
  Show dependency treegraph
Reported: 2001-02-17 11:07 EST by Pekka Savola
Modified: 2007-04-18 12:31 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-02 10:49:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pekka Savola 2001-02-17 11:07:17 EST
This is probably a more generic problem due to a coding style, but it happened to me with 
OpenSSH, so I'll put it in the record here.

(just trying to start sshd when it's already running)

# ./sshd -d
socket: Invalid argument
debug1: Bind to port 22 on
fatal: Cannot bind any address.
# echo $?

# ./sshd
# echo $?

With './sshd', the same fatal message is printed to syslog.


Now, the init script e.g. does:

        action $"Starting $prog: " /usr/sbin/sshd
now RETVAL is 0 (as above), even though sshd really fatal()'ed out with 255 exit code.

Kevin Steves <stevesk@sweden.hp.com> explained on openssh-univ-dev@mindrot.org list:
this one has forked and detached from the terminal at the point of that
error.  its parent does exit(0) in daemon() which is what the shell

So, it'd appear RETVAL or exit codes are not always too reliable.  Luckily in this case it doesn't really
matter that RETVAL is mistaken to be 0.
Comment 1 Tomas Mraz 2005-02-02 10:49:14 EST
This is not a bug but rather a feature of the current SYS V init
scripts style code. The RETVAL can reflect only errors before the
daemonization happens. There is nothing we can do with that.

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