On Wednesday July 30, gzp-2g/[email protected] wrote:
> * Steve Dickson <[email protected]>:
>
> | > | In general, if there are file(s) in /var/lib/nfs/sm (or /var/lib/nfs/statd/sm
> | > | depending on your distro) means sm-notify did not work. With Fedora, doing
> | > | a 'service nfslock restart' will cause sm-notify to be rerun... I'm not
> | > | sure how to do that with other distros...
> | >
> | > Those dirs are empty.
> | So either there were no locks to recover or sm-notify did indeed work...
>
> How sm-notify works in general? Called by statd?
Yes, it will be called by statd (unless -L was given).
It can also be run separately.
> If first time works, pid file left and second time didn't run as you
> mentoided. So something wrong here...
No, nothing wrong there.
sm-notify only needs to run once per boot, to tell peers (either
servers or clients) that this system has rebooted. It deliberately
ensures that if you run it a second time it just exits.
There is even a comment in the source:
/*
* Record pid in /var/run/sm-notify.pid
* This file should remain until a reboot, even if the
* program exits.
* If file already exists, fail.
*/
This assumes that early in reboot /var/run gets cleared. If this
doesn't happen it could be awkward.
NeilBrown