Bug 28146 - RETVAL=$? isn't always reliable due to daemon()/fork()
Summary: RETVAL=$? isn't always reliable due to daemon()/fork()
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: openssh   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-17 16:07 UTC by Pekka Savola
Modified: 2007-04-18 16:31 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Pekka Savola 2001-02-17 16:07:17 UTC
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
[snip]
socket: Invalid argument
debug1: Bind to port 22 on 0.0.0.0.
fatal: Cannot bind any address.
# echo $?
255

# ./sshd
# echo $?
0

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

---

Now, the init script e.g. does:

---
        action $"Starting $prog: " /usr/sbin/sshd
        RETVAL=$?
---
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
sees.
---

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 15:49:14 UTC
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.