This is when sendmail is ran from virecover. Is this because sendmail is taking redirection, and it needs to flock() for that?
I think a solution could be to make virecover called later on. Why are rpc.lockd and rpc.statd not started directly after rpcbind? Here is some more output. Recovering vi editor sessions:Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: SYSERR(root): cannot flock(./dfh5913dfn000292, fd=3, type=2, omode=40002, euid=25): Operation not supported collect: Cannot write ./dfh5913dfn000292 (bfcommit, uid=25, gid=25): Operation not supported cannot flock(./tfh5913dfn000292, fd=5, type=6, omode=40001, euid=25): Operation not supported cannot flock(./tfh5913dfn000292, fd=5, type=6, omode=40001, euid=25): Operation not supported Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: SYSERR(root): collect: Cannot write ./dfh5913dfn000292 (bfcommit, uid=25, gid=25): Operation not supported Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: SYSERR(root): cannot flock(./tfh5913dfn000292, fd=5, type=6, omode=40001, euid=25): Operation not supported Jun 8 21:03:39 photon sendmail[292]: h5913dfn000292: queueup: cannot lock ./tfh5913dfn000292: Operation not supported Here is what Control-T does load: 0.20 cmd: sendmail 292 [pause] 0.02u 0.04s 0% 2016k --- Robert Watson <[EMAIL PROTECTED]> wrote: > On Sat, 7 Jun 2003, David Yeske wrote: > > > Jun 8 00:52:33 photon sendmail[293]: h584pRfm000293: SYSERR(root): cannot > > flock(./tfh584pRfm000293, fd=5, type=6, omode=40001, euid=25^C. > > NFS access cache time=2 > > Starting statd. > > Starting lockd. > > > > It looks like sendmail starts before rpc.lockd and rpc.statd? This will > > cause diskless clients to hang? This is a nfs server and diskless > > client running 5.1-RELEASE. I'm running rpc.lockd and rpc.statd on the > > server and the client. Should rpc.lockd and rpc.statd be started before > > sendmail starts? > > Hmm. It shouldn't cause diskless clients to hang, or at least, doesn't > for me. The cause of the error message, however, is exactly as you > surmise -- befpre rpc.lockd, calls to flock() on the NFS file system will > return an error. Is the hang you're seeing immediately after the > "Starting lockd"? If you hit Ctrl-T, does it tell you anything useful? > Note that unless you're running 5.x pretty close to the release, pressing > Ctrl-T while a process is attempting to grab an NFS-backed file lock will > result in a slipped lock and many nasty failure modes. I disabled signal > delivery to processes while sleeping on an NFS lock as a workaround until > out rpc.lockd addresses the "process aborts the lock request" race, which > isn't handled right now. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > > __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
