On 11/30/2012 08:34 AM, Steve Langasek wrote:
> Why are those sleeps there? Because the use of init scripts ensures that
> we're always racing the kernel, instead of being able to respond directly to
> events when they happen. Nearly every one of those sleeps represents *two*
> bugs: the bug the maintainer noticed that caused them to add the sleep as a
> workaround, and the remaining bug of the race condition that the maintainer
> hasn't yet tripped over and needed to fix.
Event driven init systems are cool. Debian needs such feature. No doubts
about this and all.
However, even with sysv init, you don't have to write init scripts with
random sleep values, full of race conditions. Init scripts can be written
in a much smarter way than this. They could wait for something to happen
in a loop, and not wait as much as a full second when doing polling...
(but of course, it is much harder and error prone than an event driven
system, I'm just stating that it is really possible to write things
correctly, even with sysv)
More over, most of the sleep calls you will find in init scripts (and I
believe that is what your grep shows, because that's the case on my own
laptop...) are because of:
case "${1}" in
restart|reload|force-reload)
${0} stop
sleep 1
${0} start
;;
which I don't think is (so much of) a problem in itself. Unless you
also consider the above as a race condition (which, really, could
be a real one...).
I fully agree with all you wrote, but probably, talking about "lvm2,
cryptsetup, open-iscsi, or multipath-tools" makes more sense than talking
about race coditions because of sleep calls in sysvinit scripts. (and
you can
also add openvswitch to the list.)
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50ba16a7.2020...@debian.org
