start-stop daemon

Michael A. Peters mpeters at
Tue Apr 22 21:09:55 PDT 2003

On Tue, 2003-04-22 at 03:53, Ronald Hummelink wrote:
> On Tue, 2003-04-22 at 05:49, Michael A. Peters wrote:
> > Anyway - my statusproc() function is attached.
> > This with the Debian start-stop-daemon eliminates dependency upon a
> > particular version of pidof. So if you guys want it, here it is.
>    FULLPATH="`/usr/bin/which $2 2> /dev/null`"
>         if [ $? -ne 0 ]; then
>                 echo "I do not know about $2. It is not in my path."
>                 echo "My path is $PATH"
>                 exit 1
>         fi
> 1) this adds a dependency on the which binary/hack/... which is not part
> of base-lfs

Yes, it does. A bash function could so so easily be written to do that -
but the binary will be faster. It is a very common binary for people to
want to have on their system anyway.

> 2) this depends on the binary being in the path, which is not at all
> sure (why should I have some services in the path at all?)

A symlink in the path takes care of that.
IE ln -s /usr/X11R6/bin/xfs /usr/sbin/xfs
ln -s /opt/whatever/tools/daemon /usr/sbin/daemon

Works flawlessly. And is a pretty common practice anyway.
btw - if the daemon isn't in your patch, existing loadproc() would have
a problem with it too. Unless you specify full path (perhaps I should
test $2 to see if it is a full path arguement)

>  # Depends upon a compliant daemon with pid file where it is SUPPOSE to
> be - /var/run
>        # Daemons that have their PID file elsewhere are incorrect.
> 3) Too bad the daemon is incorrect. Your script fails miserably on this.

It would be easy to make the script work with daemons that are not
compliant. Incredibly easy. I did not want that.

What fails miserably are daemons that are NOT compliant - a pid file can
be extremely difficult to locate if you don't know where it is. That is
why any daemon that doesn't have its PID file in /var/run needs to be

For daemons w/o PID files - Debians start-stop-daemon can create one for
it with a switch.

> Should the script demand things that are simply not happening in the
> real world (tm) ?

imho, yes it should. If a daemon source code is so convoluted to make it
difficult to write a patch that puts the PID file where it should go -
then I'm guessing that daemon probably shouldn't be on my system anyway
because convoluted code is usually exploitable - not what you want with
a daemon.

> I don;t think this should replace the current statusproc function in
> this form.

Probably not - users just need to make sure they have the correct pidof

But I like Debian's start-stop-daemon anyway - and with that, I could
remove three of the functions, leaving statusproc as the only function
that still used getpids(). Rewriting it to be friendlier to the non
sysVinit pidof allowed me to completely eliminate the function that was
picky on the version of pidof.
Michael A. Peters <mpeters at>

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list