Michael A. Peters
mpeters at mac.com
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
> 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
> 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 mac.com>
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev