sendmail starts before rpc.statd and rpc.lockd

[David Yeske]

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 <rwatson at freebsd.org> 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
> robert at fledge.watson.org      Network Associates Laboratories
> 
> 

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com