Dejan Muhamedagic wrote:
Hi,
Forgive my ignorance, but I'd really appreciate if somebody could
explain the following excerpt from Filesystem:
# By sending both signals twice, we eliminate the need
# for `sleep` after them.
for sig in SIGTERM SIGTERM SIGKILL SIGKILL; do
if [ $blockdevice = "yes" ]; then
$FUSER -$sig -m -k $DEVICE
else
$FUSER -$sig -m -k $MOUNTPOINT
fi
How is exactly need for sleep eliminated? What I see is that
processes are not given enough time for cleanup.
Well...
I didn't write this code (and I don't like it) - and it has been the
focus of lots of controversy, and complaints. Everyone wants to do it
better. So, you'll have to stand in line to complain about it ;-) Just
remember that when you get in line, I was here first ;-)
Well... fuser isn't an instantaneous command. So, it does add some delay.
However, this is a broken approach, IMHO.... But, mainly for different
reasons than you point out.
And, it's not just the user process you're waiting for - it's also the
kernel.
The unmount loop probably ought to look something like this:
for signal in SIGTERM SIGTERM SIGTERM SIGKILL SIGKILL
do
if umount $args; then break; fi
fuser -m $signal ${whatever}
sleep 1
done
The advantages of this are:
The fuser (which sometimes hangs) is only done if the umount fails
(it shouldn't fail if dependent resources have stopped)
It quits as soon as the umount succeeds, and never waits extra time
It is a little more patient waiting for the processes to clean up
It uses the -m flag on fuser
Of course, this sample code doesn't properly set exit codes - which is
really important...
But, if you search the archives, you'll probably find a litany of
comments and complaints about it. Some of them have already been fixed.
Do you want to produce a patch that incorporates these ideas for us to
all complain about jointly -- I mean incorporate? ;-)
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
