Actually I was more thinking that your code waits for a condition to
become false before continuing, on the assumption that it has been true
at some point in the past.
When in fact, the very nature of asynchronousity means that the
condition may be yet to become true when this code runs.
Upstart may be fully intending to run kernel-helper, but may simply not
have gotten around to it yet. Your test passes, you start your code,
and kernel-helper comes along later and thwarts you right at the point
you thought you'd guarded.
You could vaguely rely on Upstart's goal for the job that runs kernel-
helper, it will be "start" at any point after the runlevel 2 event until
kernel-helper has actually exited. Obviously this only guards against
being run from Upstart...
while status last-good-boot | grep -q '(start)'; do
sleep 1
done
You could even avoid a sleep here ;)
initctl jobs | sed -n -e '/^last-good-boot (stop)/q' &
WAIT=$!
if status last-good-boot | grep -q '(stop)'; then
kill $WAIT
else
wait $WAIT
fi
But we're still skirting around the merciless murder of kittens going on
in the background.
Could you not take a debconf lock out, where you wait for it to be free
(assuming last-good-boot has a debconf lock while it tries to run?)
--
awful hack to avoid kernel-helper debconf clash
https://bugs.launchpad.net/bugs/261543
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
