On Thu, Apr 05, 2007 at 12:16:43PM +0900, Jun Kuriyama wrote: > At Wed, 8 Mar 2006 19:57:22 -0500, > Kris Kennaway wrote: > > > No, no, you got me wrong. The pidfile is left locked after cron stopped > > > running (with /etc/rc.d/cron stop). This behaviour must be wrong. > > > > OK, I misunderstood. The rc.d script will signal cron to kill it, > > which should be closing the file descriptors and causing rpc.lockd to > > release the lock. Perhaps this part is broken. OK, I tested this > > with daemon -p, and it indeed seems to be broken: > > > > haessal# daemon -p pid_file sleep 100000 > > haessal# kill -KILL `cat pid_file` > > haessal# ps -p `cat pid_file` > > PID TT STAT TIME COMMAND > > haessal# lockf -t 0 pid_file echo Yay > > lockf: pid_file: already locked > > Interesting. I just do little investigation. Our daemon(8) locks a > file before fork(2), which makes NFS lock registration with svid(PID) > of daemon(8) process. > > When above sleep(1) killed, this process has another PID than > daemon(8)'s, and request NFS unlock call with sleep(1)'s svid(PID). > > Our rpc.lockd(8) refuses this request because of svid unmatch. > > Which side should be fixed, daemon(8) and rpc.lockd(8)?
You're replying to a year-old mail...but rpc.lockd is the broken thing, it assumes the pid that unlocks a file must be the pid that locks it. But this is false because in UNIX file descriptors may be passed around between processes, as in the above situation. Kris
pgpVukq68TwV1.pgp
Description: PGP signature
