Procmail over NFS Robustness
"Wes L. Zuber" <[email protected]> Sat, 11 Oct 2003 07:59:10 -0700
| Newsgroups | gmane.mail.procmail.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi there,
We think that in our particular setup of using procmail to deliver over
NFS is not as robust as it could or should be due to some issue with
NFS.We have been able to strengthen procmail in our case to get around
the NFS issues. I hope that the list will consider our suggestions for
making procmail a bit more NFS resistant.
There is a retry mechanism in writefolder that we modified to:
(errno!=EEXIST&&lstat(buf2,&stbuf)&&errno==ENOENT&&lstat(buf,&stbuf)&&er
rno!=ENOENT&&
!rename(buf,buf2))
the part we added was to do a check lstat on buf (buf2 was already
being checked). We were getting some errno==4 (Interrupted system call)
which we interpreted to mean as a missed NFS call. Our mod seemed to
fix this issue here.
This slowed down the errors in our sendmail log quite a bit (after
fixing the retry bug and adding this mod). We started noticing the
sendmail reported error "Can't create output" about once per hour per
server (4 servers).
After doing some more tracking we saw that the trymkdir routine was
failing even though the directory was clearly there. Again we were
getting errno==4 (Interrupted system call) and the trymakedir would
fail and other routines would try to make the dirs (which were really
there) and they would fail and so on.
We changed
else if(errno!=ENOENT) /* something more fundamental went
wrong */
break;
to:
else if(errno!=ENOENT) /* something more fundamental went
wrong */
{
fprintf(stderr,"TRYMKDIR ENOENT:%s< errno:%d<\n",dir,errno);
}
so we just removed the break (the fprint is just our diagnostic dump)
and let it retry.
This fixed the issue for us. And after 8 hours we don't see anymore of
the "Can't create output" errors in the sendmail log.
Thanks,
--Wes, ULTIMATE Internet Access