On Thu, Mar 22, 2007 at 08:56:28AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Mar 2007, Steve Langasek wrote:
> > That's not what --oknodo means. Please see the manpage; --oknodo is exactly
> > what's wanted here.
> Was start-stop-daemon fixed, then? In the past --oknodo behaved
> differently, which is the reason for the ammount of code in amavisd-new to
> make sure "not running" can be told apart from "failed to stop"...
Sorry, I'm not aware that --oknodo ever behaved differently; this has been
the documented behavior as far as I remember.
But it's certainly possible to get a false negative if using --exec with
--stop, as I mentioned, because s-s-d will simply fail to recognize that a
running process is one that should be stopped. So maybe that's the problem
you're thinking of?
> > Does this mean you don't have time (even with a patch), and would like an
> > NMU?
> NMUs are usually welcome when I don't respond promptly. In fact, timidity
> has been NMUed already...
> I won't object to NMUs (0-day or delayed) to fix timidity. As long as
> they're done properly, with a NMU patch sent to the BTS, etc, they're
> welcome.
Ok, please find attached the diff for an NMU that I'll be uploading shortly.
On Fri, Mar 23, 2007 at 12:56:31AM +0200, Eddy Petrișor wrote:
> Yes, I should never send patches when I am tired :-) I was trying
> something along the lines of the code below.
> - - if start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
> - - --exec ${DAEMON} --retry 10 ; then
> + if start-stop-daemon --stop --quiet --oknodo --pidfile
> ${PIDFILE} \
> + --signal TERM/3/TERM/3/KILL/10; then
> Still I wasn't sure if it would make any difference to try to TERM
> twice and I ended up in sending a half baked/broken patch.
Surely not relevant to the problem at hand; I wouldn't mess with the kill
signals unless there's a concrete problem with stopping processes once
they've been identified.
> OTOH, Steve, you said that the --exec option should not be used, but
> I see the same type of code for many other daemons on my system, so
> the issue you are talking about should happen for these binaries,
> too, shouldn't it?
Yes. And it does, and it's a problem. :)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
diff -u timidity-2.13.2/debian/changelog timidity-2.13.2/debian/changelog
--- timidity-2.13.2/debian/changelog
+++ timidity-2.13.2/debian/changelog
@@ -1,3 +1,16 @@
+timidity (2.13.2-7.3) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * High-urgency upload for RC bugfix.
+ * Call start-stop-daemon with --oknodo when stopping timidity in the
+ init script, so that a stopped daemon isn't treated as an error on
+ upgrade. Closes: #414929.
+ * Also, don't use --exec with start-stop-daemon --stop, as this will
+ fail to find a running daemon if the on-disk binary has been moved
+ out from under us for any reason; use --name instead.
+
+ -- Steve Langasek <[EMAIL PROTECTED]> Thu, 22 Mar 2007 16:05:48 -0700
+
timidity (2.13.2-7.2) unstable; urgency=low
* Non-maintainer upload with maintainer permission.
diff -u timidity-2.13.2/debian/timidity.init timidity-2.13.2/debian/timidity.init
--- timidity-2.13.2/debian/timidity.init
+++ timidity-2.13.2/debian/timidity.init
@@ -52,8 +52,8 @@
;;
stop)
echo -n "Stopping $DESC: "
- if start-stop-daemon --stop --quiet --pidfile ${PIDFILE} \
- --exec ${DAEMON} --retry 10 ; then
+ if start-stop-daemon --stop --quiet --oknodo --pidfile ${PIDFILE} \
+ --name $(basename ${DAEMON}) --retry 10 ; then
echo "timidity."
else
echo "(failed)."
