sendmail starts before rpc.statd and rpc.lockd

[Robert Watson]

On Sun, 8 Jun 2003, David Yeske wrote:

> This is when sendmail is ran from virecover.
> 
> Is this because sendmail is taking redirection, and it needs to flock()
> for that? 

Generally, sendmail uses flock() on the aliases file and related databases
to ensure consistency.  As far as I know, it's unrelated to redirection.

> I think a solution could be to make virecover called later on.  Why are
> rpc.lockd and rpc.statd not started directly after rpcbind?

No idea.  Moving virecover later is a possibility; probably the missing
piece is that sendmail should depend on rpc.lockd, ordering-wise.  Or
perhaps, it should depend on late-stage file system bits, and the file
system bits don't probably depend with the rpc bits.

> 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

pause, eh?  That doesn't sound like it's related the the NFS locking. 
Note that the errors you get for sendmail due to lack of locking result in
a fairly clean exit, not a hang.  Hangs are generally associated with DNS.
Try a packet sniff?