Bugzilla Bug 143951

I have an (in-house) daemon where my initscript does the following:

- uses start-stop-daemon to start a shell script which
- performs some initialization and
- exec's a python script which
- performs some initialization and
- changes its name from 'python /path/to/foo.py' to 'foo'

thus, the same PID will be '/bin/bash /path/to/wrapper', then 'python
/path/to/foo', then 'foo' at fairly unpredictable times.  This was fine with
the previous version of baselayout (in fact, we didn't do the last name-change
-- it was added to try to fix this), but produces a race condition with this
version.

Specifically, if I use "--name foo" in the s-s-d invocation, then *if* the
daemon gets to its name-changing within the one second allowed by
rc_start_daemon, things will work.  Otherwise, s-s-d kills the nascent daemon.

It seems that start-stop-daemon should be configurable to look *only* at the
PID of the daemon it's starting, for cases just like this one.  Other options
might be allowing the wait-for-name-stabilization timeout to be configurable (a
la RC_RETRY_TIMEOUT/RC_RETRY_COUNT).

I'd appreciate either an idea on how to fix this or a suggestion of a
future-portable way for me to fix my  app.

(In reply to comment #0)
> - uses start-stop-daemon to start a shell script which
> - performs some initialization and
> - exec's a python script which
> - performs some initialization and
> - changes its name from 'python /path/to/foo.py' to 'foo'

start-stop-daemon starts and stops daemons, not shell scripts. If you have a
shell script that does initialisation, and then called another script (ie
python) why even use start-stop-daemon?

> 
> thus, the same PID will be '/bin/bash /path/to/wrapper', then 'python
> /path/to/foo', then 'foo' at fairly unpredictable times.  This was fine with
> the previous version of baselayout (in fact, we didn't do the last name-change
> -- it was added to try to fix this), but produces a race condition with this
> version.

s-s-d now monitors daemons started and stopped so we know if a daemon exited
when it shouldn't have done.

s-s-d has the advantage of tight integration with the Gentoo initscripts, which
is helpful.  I took the time to rewrite the Python scripts as daemons (using
e.g., http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/278731).

The scripts are invoked as e.g., '/lib/daemons/bin/foobar', but run with the
following in /proc/*/cmdline:
 python /lib/daemons/bin/foobar --daemonize=TRUE
--daemon-log-file=/var/log/foobar_daemon.log --pid-file=/var/run/foobar.pid
/proc/*/stat contains 'python2.4'. 

It would seem from the manual page that s-s-d will use --name as the argument
to 'pidof':
       -n|--name process-name
              Check for processes with the name process-name (according to
/proc/ pid /stat ).
yet in /lib/rcscripts/sh/rc-daemon.sh, rc_start_daemon calls is_daemon_running
with ${cmd}, not ${name}, meaning that it runs 'pidof /lib/daemons/bin/foobar',
which it does not find.  I consider this latter circumstance a bug, though
admittedly not the bug I had originally reported.  I've attached a patch to fix
it.

With this patch in place, and with a change to my daemon such that it changes
its cmdline and stat to 'foo', I can effectively use

  start-stop-daemon ... --name foobar --startas /lib/daemons/bin/foobar

to control the daemon.  Without this patch, I must use:

  start-stop-daemon --startas python -- /lib/daemons/bin/foobar

which is obviously less than ideal if there are multiple python-based daemons.

I'm sorry this took me a while to get around to the central problem -- it's
rather new territory to me.

Created an attachment (id=94344) [edit]
patch to /lib/rcscripts/sh/rc-daemon.sh to use ${name} as the manpage says it
will

Created an attachment (id=94347) [edit]
smaller patch

I cannot fault your argument, and thanks for the patch :)

This patch is smaller and less intrusive but should achieve the same thing.
Please test that it works for you.

Looks great -- thanks!

Fixed in baselayout-1.12.4-r6 :)

Sorry I don't get the solution for this problem here. Since the upgrade s-s-d
failed to start my perl daemon. I use the following line:

start-stop-daemon --start --quiet --pidfile /var/run/xrd.pid \
--exec /usr/sbin/xrd.pl -- --daemonize

The '/usr/sbin/xrd.pl' is a perl daemon which changes its name to 'xrd' and
forks into the background.

'/etc/init.d/iqadm-xrd' fails to start the daemon but entering the above
command directly will work. Two thinks are worth mentioning:

a) Why the difference between the command in the startup script and the command
on the command line?

b) Why is the start of the service failing? An better explanation would be
useful here: 'Failed to start xrd' is a little bit (too) short. B-)

(In reply to comment #7)
> Sorry I don't get the solution for this problem here. Since the upgrade s-s-d
> failed to start my perl daemon. I use the following line:
> 
> start-stop-daemon --start --quiet --pidfile /var/run/xrd.pid \
> --exec /usr/sbin/xrd.pl -- --daemonize
> 
> The '/usr/sbin/xrd.pl' is a perl daemon which changes its name to 'xrd' and
> forks into the background.

So use the --name directive

> '/etc/init.d/iqadm-xrd' fails to start the daemon but entering the above
> command directly will work. Two thinks are worth mentioning:
> 
> a) Why the difference between the command in the startup script and the command
> on the command line?
> 
> b) Why is the start of the service failing? An better explanation would be
> useful here: 'Failed to start xrd' is a little bit (too) short. B-)

init scripts have a bash wrapper around s-s-d to check the daemon in question
really did start and not bail through a configuration issue. The downside is
that you now need to use the --name directive for some perl/python/bash
scripts.