On Wed, Aug 17, 2011 at 03:50:24PM +0200, Petter Reinholdtsen wrote: > [Adi Kriegisch] > > I am currently running into this exact situation with /etc/init.d/ocfs2: > > The script takes care of (un)mounting all ocfs2 volumes. > > In my case I have 11 volumes to be unmounted which takes some time, > > sendsigs tries to kill "umount -a -t ocfs2" which leads to an open > > heartbeat on exactly one volume (the one unmounted in parallel with > > "sendsigs" trying to kill umount). > > Is it enough to make sure the script run before sendsigs? If not, why > do you need to run it alone? Yes, it is enough to run the script either before or after sendsigs. Actually the ocfs2 script *could* even run in parallel with sendsigs, provided sendsigs does not kill this script's tasks. ;-) > > In case you think that this is an issue with ocfs2-tools (the > > package providing /etc/init.d/ocfs2), please tell me what a > > good/working LSB header would look like. From what I've read I'd > > rather think that a script that needs to run in an exclusive fashion > > should indicate that (which means that this bug needs to be > > reasigned to initscripts which provides /etc/init.d/sendsigs). > > I would suspect changing the header to make sure the script is running > before sendsigs would be enough, but I do not really understand the > problem. The problem is that a script (sendsigs) is killing tasks from other init scripts that happen to run in parallel to it. This has started to happen since the switch to insserv, obviously. I consider a script that acts destructive to other scripts without even giving a hint (aka "need to run exclusively") a problem. IMHO sendsigs needs to avoid killing stuff from other scripts. Actually I am quite surprised that ocfs2 is obviously the only script affected by this...
So in your opinion the right way to deal with the issue is to file a bug against ocfs2-tools telling them that it is necessary to add a dependency on sendsigs to avoid getting killed when using more than just some volumes (I think this started to take too long to umount at around 7 or 8 volumes)? Thanks for your quick response! -- Adi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
