2008-07-30 23:18:46

by NeilBrown

[permalink] [raw]
Subject: Re: [PATCH] mount.nfs command: old glibc missing some flags

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.