Hi! On Wed, 2019-11-27 at 03:39:20 +0000, Dmitry Bogatov wrote: > control: tags -1 +confirmed > > [2019-11-25 12:06] Jan Braun <janbr...@gmx.de> > > The /lib/init/init-d-script errorneously returns failure when asked to > > stop a non-running service: > > [...] > > > > And indeed, one call to start-stop-daemon in /lib/init/init-d-script is > > missing the --oknodo flag. Namely, the first call in the stop action: > > [...] > > Adding --oknodo in line 76 (line 2 in the quote) should fix this bug. > > Thank you very much for your detailed analysis. I included --oknodo flag > as you suggested. Unless there is objections in upcoming few days, I > will upload it. > > > Additionally, I'd like to point out that the calculation of the return > > code in this function seems fishy to me: it will always be the return > > code of the first s-s-d invocation, unless the second invocation returns > > 2 (which aiui means "a process survived SIGKILL" in this context). > > Wouldn't taking the maximum (or sum) of the two return codes be more > > sensible? > > Sum is definitely not apporiate, since there is standard that specifies > meanings of error codes of init.d script[^1]. But you raise valid point, > and it is not clear to me why exit code 2 is handled specially. > > Also, returning 2 should mean "invalid or excess argument(s)", > which is not the case. Should't we return exit code 1 in all cases when > s-s-d fails?
Actually, and this is something I've had pending raising for a long time, I don't understand that two s-s-d invocations pattern in stop which seems a bit pointless TBH? The --retry should make s-s-d wait for the child to exit, or terminate it forcibly. I also don't understand the diverging --name usage, because DAEMON cannot have a different name to the --startas argument anyway, so it cannot be used for interpreted scripts. Thanks, Guillem
