On Thu, Dec 17, 2009 at 11:18:53AM -0500, Chuck Lever wrote: > run_sm_notify() simply forks and execs the sm-notify program. This > program checks for the existence of a pid file. If the pid file exists, > then sm-notify exits. If it does not, then sm-notify retires the records > in /var/lib/nfs/statd/sm and posts reboot notifications. > > 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. > > So the root cause of this problem is that the current mechanism sm- > notify uses to detect a reboot is not portable across distributions. > > My new-statd prototype used a semaphor instead of a pid file to detect > reboots. A semaphor is shared (visible to other processes) and will > continue to exist until it is deleted or the system reboots. It is a > resource that is not destroyed automatically when the sm-notify process > exits. If creating the semaphor fails, sm-notify exits. If creating it > succeeds, it runs. > > Would anyone strongly object to using a semaphor instead of a pid file > here? Is support for semaphors always built into kernels? Would there > be any problems with the small size of the semaphor name space? Is there > another similar facility that might be better? I don't know much about those (except that I think there's an e at the end); looks like sem_overview(7) is the place to start? It says: " Prior to kernel 2.6, Linux only supported unnamed, thread-shared sema‐ phores. On a system with Linux 2.6 and a glibc that provides the NPTL threading implementation, a complete implementation of POSIX semaphores is provided." So would it mean dropping support for 2.4? --b. -- 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
