> Generally, sendmail uses flock() on the aliases file and related databases
> to ensure consistency. As far as I know, it's unrelated to redirection.
And for locking queue files.
> > Here is what Control-T does
> > load: 0.20 cmd: sendmail 292 [pause] 0.02u 0.04s 0% 2016k
>
> pause, eh? That
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'
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
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 an
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.
I should clarify that /etc/rc.d/virecover is calling sendmail.
Does virecover need to be called this ea
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
han