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
