On Wed, Oct 04, 2000 at 10:38:33PM +0200, Peter van Dijk wrote:
> On Wed, Oct 04, 2000 at 03:18:35PM -0500, Kris Kelley wrote:
> [snip]
> > So far my results have been successful. All is well when the network is
> > behaving itself, and qmail defers messages properly when qmail-getpw fails
> > due to a bad network connection. A contingency for a failed NFS mount is
> > one of my last hurdles to getting this all in place. I'm open to any ideas,
> > from .qmail tricks to code patching.
>
> Ok, let's do this out of order.
> .qmail tricks - doing a deferral from ~alias/.qmail-default if the user
> seems valid?
>
> Or, *duh*: the homedir check is in qmail-getpw. Since you've already
> modified it, modify it some more :)
Right. But he may not actually have to check for the existance of HOME currently
and in any event there is a timing window between qmail-getpw and the
invocation of qmail-local. So it may disappear after the check in qmail-getpw.
Having said all that, qmail-local exit with a *temp* error if it cannot
stat the home directory, so I'm not sure what the exact problem is. If the
nfs home is gone, then this stat() should fail at some point and defer
the delivery.
The only general problem is that the NFS timeouts may clog the concurrencylocal
limits, but then if you have no homes, there's nothing to delivery anyway.
code frgament:
if (stat(".",&st) == -1)
strerr_die3x(111,"Unable to stat home directory: ",error_str(errno),". (#4.3.0)");
doc fragment:
111 means that the delivery
failed but should be tried again in a little while (soft
error).
Regards.
