On Dec 17, 2009, at 6:14 PM, Neil Brown wrote:
On Thu, 17 Dec 2009 11:18:53 -0500
Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
Jeff Layton pointed out to me yesterday that Red Hat's nfslock script
unconditionally deletes sm-notify's pid file every time "service
nfslock start" is done, which effectively defeats sm-notify's reboot
detection.
sm-notify was written by a developer at SuSE. SuSE Linux uses a
tmpfs
for /var/run, but Red Hat uses permanent storage for this directory.
Thus on SuSE, the pid file gets deleted automatically by a reboot,
but
on Red Hat, the pid file must be deleted "by hand" or reboot
notification never occurs.
Just to make sure the facts are straight:
SuSE does not use tmpfs for /var/run (much as I personally think that
would be a very sensible approach for both /var/run and /var/locks).
It appears that Debian can use tmpfs for these, but doesn't by
default.
Both SuSE and Debian have boot time scripts that clean up /var/run
and other
directories. They remove all non-directories other than /var/run/
utmp.
If Redhat doesn't clean up /var/run at boot time, then I would think
that is
very odd. The files in there represent something that is running.
At boot,
nothing is running, so it should all be cleaned up. Are you sure
Redhat
doesn't clean out /var/run???
I just had a look at master.kernel.org (the only fedora machine I
can think
of that I have access to) and in /etc/rc.d/rc.sysinit I find
find /var/lock /var/run ! -type d -exec rm -f {} \;
So I'm thinking that if you just remove
# Make sure locks are recovered
rm -f /var/run/sm-notify.pid
from /etc/init.d/nfslock, then it will do the right thing.
Makes sense. Steve, can you look into this for supported releases
(like F12 and RHEL5)? Or, perhaps you can clarify why that "rm" is
required.
Meanwhile, I'm going to prototype a mechanism that tries to use the
kernel's boot_id, if present.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
