Bug 12295 - Bug in /etc/rc.d/init.d/functions not starting daemon
Summary: Bug in /etc/rc.d/init.d/functions not starting daemon
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-06-15 09:59 UTC by Chris Bitmead
Modified: 2014-03-17 02:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-06-15 09:59:58 UTC
Embargoed:


Attachments (Terms of Use)

Description Chris Bitmead 2000-06-15 09:59:55 UTC
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 05:18:09 UTC
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.