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