On Wednesday July 30, gzp@xxxxxxx wrote: > * Steve Dickson <SteveD@xxxxxxxxxx>: > > | > | 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 -- 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
