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

[Neil Brown <neilb@suse.de>]

On Wednesday July 30, gzp-2g/1Y3AqmNE@public.gmane.org wrote:
> * Steve Dickson <SteveD@redhat.com>:
> 
> | > | 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