if you use the (deprecated) --oknodo flag start-stop-daemon will return all time 1 instead of 0 when the daemon is successfully stopped (or started). As Result an init.d-Script "failes" to stop/start the daemon also if it is successfully stopped/started. The init.d-Script has to be manually zapped every time (if --oknodo is only used on stop() ). Reproducible: Always Steps to Reproduce: 1. run /sbin/start-stop-daemon --stop --oknodo --quiet --pidfile /var/run/daemon-program.pid --exec /usr/bin/daemon-program --retry 30 -- --optional --args && echo "OK" || echo "FAILED" 2. get FAILED every time even on successful stop Actual Results: start-stop-daemon returns 1 instead of 0 on successful operations if --oknodo is used Expected Results: start-stop-deaemon should show the warn message but should return 0 for successful operations example init-Script for above mentioned behaviour. start() { ebegin "Starting Program" /sbin/start-stop-daemon --start --quiet --pidfile $PID --exec $BIN eend $? } stop() { ebegin "Stopping Program" /sbin/start-stop-daemon --stop --oknodo --quiet --pidfile $PID --exec $BIN --retry 30 eend $? }
I'm just curious.. why do you use --oknodo for stop() at all?
Hum good question. it is several month ago since i've written the initscript where i discovered this behavior. but i think it was because i got error messages or "failed to stop"-messages when stopping the program without --oknodo but i'm not really sure. but beside that i think marking an option deprecated as should only display an error message and not change the behavior of it and imho returning 1 when it is used instead of 0 on successful operations is an behavior change. i changed my init script to not use --oknodo anymore but i don't know if there are any other init scripts in portage packages which use oknodo and would fail to start/stop like mine does before removing --oknodo from it. regards Christoph
Well.. I think I have to close this bug as INVALID because the manpage of baselayout1 clearly says: "Return exit status 0 instead of 1 if no actions are (would be) taken. *if no actions ...* So its basically used in cases like reload or so, where only a signal must be send to the process *without* actions like start/stop. If you try --oknodo together with e.g. --signal and it still returns 1 instead of 0 then feel free to reopen this bug. IMHO OpenRC behaves correct as it seems to return the real exit status of the action in this case.
but the (old) manpage also says -K, --stop Checks for the existence of a specified process. If such a process exists, start-stop-daemon sends it the signal specified by --signal, and exits with error status 0. If such a process does not exist, start-stop-daemon exits with error status 1 (0 if --oknodo is specified). If --retry is specified, then start-stop-daemon will check that the process(es) have termi- nated. (source: http://man.he.net/man8/start-stop-daemon) so why should --oknodo not used with stop?
and by the way. it DOES an action it actually stops the daemon so it should return 0 (because it successfully stops it) without --oknodo it returns 0 with --oknodo it returns 1
My opinion is that since --oknodo is deprecated this bug should be closed as WONTFIX. Does anyone on the team disagree?
There have been no objections, so I am closing this as wontfix. This option is deprecated so it should not be used, and scripts that are using it are broken.
