We have a patch waiting for pre-approval at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704833
Kind regards, Ralf On 15/04/13 21:47, Tomas Pospisek wrote: > Frode Severin Hatlevik writes: > >> When calling '/etc/init.d/virtuoso-opensource-6.1 stop', virtuoso may >> still be running after the script completes. This might lead to >> database corruption, e.g. on system reboot. >> >> [...] >> >> I have modified the script to temporarily circumvent the situation on >> my system by enclosing part of this snippet in a while-loop >> >> [...] >> >> If the server does not exit cleanly at some point, I have >> effectively created an infinite loop. > > Instead of looping and calling stop_server that in turn would call > start-stop-daemon, we can tell start-stop-daemon directly to wait and > retry. > > From the start-stop-daemon manpage: > > Demonstration of a custom schedule for stopping food: > > start-stop-daemon --stop --oknodo --user food --name food \ > --pidfile /run/food.pid --retry=TERM/30/KILL/5 > > So we could do something like this instead > > ########################################################################## > --- virtuoso-opensource-6.1.orig 2013-04-15 21:37:29.948141713 +0200 > +++ virtuoso-opensource-6.1 2013-04-15 21:38:53.476142007 +0200 > @@ -153,7 +153,8 @@ > # if we are using a daemonuser then look for process that match > start-stop-daemon --stop --quiet --pidfile $PIDFILE \ > --user $DAEMONUSER \ > - --exec $DAEMON > + --exec $DAEMON \ > + --retry=TERM/30/KILL/5 > errcode=$? > fi > ########################################################################## > > The timeouts are of course purely arbitrary. Do they look about OK? That > is sending a TERM, waiting 30 seconds for the process to terminate and > if it's not dead then SIGKILLing it and waiting further 5 seconds for it > to be cleaned up (that's at least how I interpret the start-stop-daemon > manpage). > > This solution would seem a lot more robust than the loop. Since I am not > running virtuoso (but trying to help to drive the wheezy RC bug count > down) I'd be nice if you Frode could test that it actually works as > expected and well? > > What do think of this solution José? > *t -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
