Bug 12295 - Bug in /etc/rc.d/init.d/functions not starting daemon
Bug in /etc/rc.d/init.d/functions not starting daemon
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-15 05:59 EDT by Chris Bitmead
Modified: 2014-03-16 22:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-06-15 05:59:58 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 Chris Bitmead 2000-06-15 05:59:55 EDT
If you write an init.d script to start a daemon - let's say it's 
the foobar daemon, you will generally write an init script
/etc/rc.d/init.d/foobar.

Now /etc/rc.d/init.d/functions uses /sbin/pidof to try and figure out if
the daemon is already running. But now the initscript is called
foobar and the daemon is called foobar. pidof always returns true
because it confuses the fact that the initscript foobar is running
with whether the daemon foobar is running. Thus the daemon is never
started because it thinks it is already running. This didn't seem to be a
problem in RH 6.1.

To make matters more confusing running "sh /etc/rc.d/init.d/foobar" seems
to work, whereas "/etc/rc.d/initd/foobar" does not work. Who knows why.

The solution is to make sure if pidof returns a pid, make sure it is not
the pid of the init script itself. This may or may not be easy if
the daemon function is run in the background, it may not have access to the
old pid. But something needs to be done. At a very bare minimum report the
reason it's not going to run the daemon and preferably document the bug in
the script if it can't be fixed.
Comment 1 Bill Nottingham 2000-08-07 01:18:09 EDT
This appears to be fixed in the pinstripe beta; I can't
reproduce it here.

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