Bug#668332: Info received (Bug#643337: dpkg: start-stop-daemon can't handle script daemon)
Update.
I removed the --name argument, and I use following values:
NAME=script_name
DAEMON=path_to_script/$NAME
DAEMON_ARGS=--args
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --background --make-pidfile
--chuid=$DAEMONUSER --pidfile $PIDFILE --startas $DAEMON --test
/dev/null \
|| return 1
start-stop-daemon --start --quiet --background --make-pidfile
--chuid=$DAEMONUSER --pidfile $PIDFILE --startas $DAEMON -- \
$DAEMON_ARGS \
|| return 2
[...]
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=INT/30/KILL/5
--pidfile $PIDFILE
[...]
Now, I get expected behaviour. That is, the script won't launch two
instances of the application, and I have an explicit status message.
Yet, the name of the executable is not checked, which means that if it
dies somehow, and a new process gets its PID, the script will stop the
new process.
I suppose a nicer way would be to get s-s-d to write the name of the
script itself ($NAME) in /proc/PID/stat, instead of the name of the
interpreter (python). I couldn't achieve this.
Am I misunderstanding something ?
--
Jérôme
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668332: Bug#643337: dpkg: start-stop-daemon can't handle script daemon
Hi. No, this all looks right, --name should usually be used on interpreted scripts and --exec otherwise. Using --name might not always be possible: start-stop-daemon: warning: this system is not able to track process names longer than 15 characters, please use --exec instead of --name. Now, even with a shorter name, I can't get it to work. For the record, I replaced the above by something like this: start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \ --name $NAME --test /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \ --name $NAME -- \ $DAEMON_ARGS \ || return 2 Here's what I have in my init script: start-stop-daemon --start --quiet --background --make-pidfile --chuid=$DAEMONUSER --pidfile $PIDFILE --startas $DAEMON --name $NAME --test /dev/null \ || return 1 start-stop-daemon --start --quiet --background --make-pidfile --chuid=$DAEMONUSER --pidfile $PIDFILE --startas $DAEMON --name NAME -- \ $DAEMON_ARGS \ || return 2 I'm using: NAME=python_script DAEMON=path_to_script/$NAME DAEMON_ARGS=--args When using start option, the pid file is created, but the name in /proc/pid/stat is python, therefore, when calling start again, a new instance is created. If I do it this way: NAME=python DAEMON=/usr/bin/python DAEMON_ARGS=path_to_script/python_script --args s-s-d will only allow one instance. Yet, it does not look so nice. And the status command outputs [ ok ] python is running. Is this the recommended way ? Or did I miss something ? By the way, while investigating this, I stumbled across this thread: http://dev.gentoo.org/~vapier/openrc/projects/openrc/ticket/164.html where there is talk about daemonizing a perl script. Apparently, s-s-d was modified to add an --interpreted flag. Not sure this is relevant. -- Jérôme -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643337: dpkg: start-stop-daemon can't handle script daemon
severity 643337 wishlist clone 643337 -1 retitle 643337 dh-make: Template could indicate when to use s-s-d --name/--exec reassign 643337 dh-make retitle -1 initscripts: Template could indicate when to use s-s-d --name/--exec reassign -1 initscripts thanks On Sun, 2012-01-15 at 00:15:31 +0100, Martin Stigge wrote: I'm reopening the bug because I ran into the same problem trying to write an initscript for a python daemon. Problem here is that the default initscript created by dh-make gives the following: start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 This causes the exact trouble as described by Étienne: the test in the first call will still succeed if run again after the second call. This results in the initscript launching another instance of the deamon (via the seemingly oblivious start-stop-deamon). I'm aware that this does not necessarily have to be considered a bug in start-stop-daemon, rather its use (and maybe a little bit of inconsistency in behavior, see #202719, or deficiency in documentation, see #367608). The last one is fixed now. I'm happy to reassign this elsewhere (possibly dh-make?) but somewhere we should have it documented, in case anyone else bumps into this. Doing so now to dh-make and initscripts (for /etc/init.d/skeleton). For the record, I replaced the above by something like this: start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \ --name $NAME --test /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \ --name $NAME -- \ $DAEMON_ARGS \ || return 2 Instead of --exec, this uses --name to match the process in case it exists and --startas to launch a new one in case it doesn't. If I got something terribly wrong, please tell me, otherwise please indicate where to forward this. No, this all looks right, --name should usually be used on interpreted scripts and --exec otherwise. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643337: dpkg: start-stop-daemon can't handle script daemon
On Sun, Jan 15, 2012 at 12:15:30AM +0100, Martin Stigge wrote: I'm reopening the bug because I ran into the same problem trying to write an initscript for a python daemon. Problem here is that the default initscript created by dh-make gives the following: start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 Btw, same thing for /etc/init.d/skeleton from the initscripts package. Regards, Martin signature.asc Description: Digital signature
Bug#643337: dpkg: start-stop-daemon can't handle script daemon
Uh, new try, had to first unarchive the bug and wait for a while.. On Tue, Sep 27, 2011 at 02:21:53PM +0200, Étienne BERSAC wrote: Well, after rereading the man page, i just need to remove the --exec option X( Sorry. Please close this bug :( Hi, I'm reopening the bug because I ran into the same problem trying to write an initscript for a python daemon. Problem here is that the default initscript created by dh-make gives the following: start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \ $DAEMON_ARGS \ || return 2 This causes the exact trouble as described by Étienne: the test in the first call will still succeed if run again after the second call. This results in the initscript launching another instance of the deamon (via the seemingly oblivious start-stop-deamon). I'm aware that this does not necessarily have to be considered a bug in start-stop-daemon, rather its use (and maybe a little bit of inconsistency in behavior, see #202719, or deficiency in documentation, see #367608). I'm happy to reassign this elsewhere (possibly dh-make?) but somewhere we should have it documented, in case anyone else bumps into this. For the record, I replaced the above by something like this: start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \ --name $NAME --test /dev/null \ || return 1 start-stop-daemon --start --quiet --pidfile $PIDFILE --startas $DAEMON \ --name $NAME -- \ $DAEMON_ARGS \ || return 2 Instead of --exec, this uses --name to match the process in case it exists and --startas to launch a new one in case it doesn't. If I got something terribly wrong, please tell me, otherwise please indicate where to forward this. Thanks! Regards, Martin signature.asc Description: Digital signature
Bug#643337: dpkg: start-stop-daemon can't handle script daemon
Package: dpkg Version: 1.15.8.11 Severity: normal Hi, Consider the case where your daemon is written in python. If you tell start-stop-daemon to exec my-daemon, a python script with a shebang, then check() will fail to verify the pid, because /proc reports 'python2.6' as the executable. If you tell start-stop-daemon to exec directly python with the script as argument, you hit a bug when you have no pid: start-stop-daemon will walk /proc searching for a python2.6 process to kill. Do you have a solution for such case ? (except using supervisord or even systemd ;) ). I guess that a good solution would be to avoid the walk through /proc to search corresponding process if there is no pidfile. I can make a patch for that if you appreciate the idea. Regards, Étienne BERSAC -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/6 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 8.5-1GNU core utilities ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii xz-utils5.0.0-2 XZ-format compression utilities ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt0.8.10.3+squeeze1 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
