Re: Unable to run qmail-remote from resource exthaustion PERMENENT error?
Pavel Kankovsky writes: According to Single Unix Spec v2, execve() may fail with ENOMEM and ETXTBSY too. And they are interpreted as temporary failures by qmail. You don't remember the details of your own code. :) Pay attention. Temporary errors during a message's lifetime produce ``deferral: Unable to run qmail-remote.'' The question here was about ``failure: Unable to run qmail-remote.'' The answer is that this failure can only be caused by permanent errors from execve(), reflecting serious configuration problems, or by OS bugs. In this case the problem was an OS bug. I agree that there's not much harm in treating all of these as temporary errors. However, no matter what qmail does, the OS bug has to be tracked down and fixed. ---Dan
Re: Unable to run qmail-remote from resource exthaustion PERMENENT error?
On 3 Feb 1999 07:56:25 -, D. J. Bernstein wrote: This is a bug in your operating system. Yes. This is where a small change in qmail could cause it to be more robust, even on a less-than-perfect OS. On bug-free systems, the only way for qmail-rspawn to generate that message is for execve() to return an error that fails error_temp(): normally ENOTDIR, ENAMETOOLONG, ENOENT, ELOOP, EACCES, ENOEXEC, E2BIG, or EFAULT. None of these can be caused by temporary failures; they are permanent (and quite serious) configuration errors. Permanent(OS) and Permanent(mail) are 2 different things. I don't see why e.g. ENOENT should cause the message to be bounced. It's not a permanent problem with the message, and over the queue-life of the message it's not a permanent config problem either. If the sysadmins doesn't fix it, it becomes a (mail) permanent error when the message times out in the queue. What happened to you, presumably, is that crt0.o tried to load a shared library, failed because it was out of memory, and incorrectly decided to exit with some arbitrary code, never mind the fact that exit codes have meanings. It should instead have terminated the process with SIGKILL. More or less. Again, the error is permanence from the point of view of the application, but shouldn't cause the message to bounce immediately. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: Unable to run qmail-remote from resource exthaustion PERMENENT error?
On Tue, Jan 26, 1999 at 08:36:39PM +0100, Rask Ingemann Lambertsen wrote: On 26-Jan-99 16:06:07, Fred Lindberg wrote something about "Unable to run qmail-remote from resource exthaustion PERMENENT error?". I just couldn't help replying to it, thus: Testing ezmlm stuff on a 486/32MB I ran into some resource exhaustion, and noticed that qmail-remote crashing is a permanent error, while an inability to fork qmail-remote is a permanent error. This seems incorrect and caused loss of a message. loss or bounce? Log (the second entry is a crash leading to the expected deferral): Jan 26 11:56:10 id qmail: 917351770.477256 status: local 0/10 remote 40/40 Jan 26 11:56:10 id qmail: 917351770.832994 delivery 7497: failure: Unable_to_run_qmail-remote./ I saw the same thing today. Resource exhaustion (memory) leading to that error message and bounced mail. Not good at all. Greetz, Peter. -- .| Peter van Dijk .| [EMAIL PROTECTED]
Re: Unable to run qmail-remote from resource exthaustion PERMENENT error?
On Wed, 27 Jan 1999 07:57:04 +0100, Peter van Dijk wrote: loss or bounce? Important semantics: bounce from the MTA point of view. Loss from the subscribers point of view. Point: This is a temporary error and should not result in a bounce. No big deal, but easy to fix. IMHO, since qmail does not have complete control over possible error codes, it seems more reasonable to make the default a temporary error and select specific error codes that lead to permanent errors. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Unable to run qmail-remote from resource exthaustion PERMENENT error?
Testing ezmlm stuff on a 486/32MB I ran into some resource exhaustion,
and noticed that qmail-remote crashing is a permanent error, while an
inability to fork qmail-remote is a permanent error. This seems
incorrect and caused loss of a message.
Log (the second entry is a crash leading to the expected deferral):
Jan 26 11:56:10 id qmail: 917351770.477256 status: local 0/10 remote
40/40
Jan 26 11:56:10 id qmail: 917351770.832994 delivery 7497: failure:
Unable_to_run_qmail-remote./
Jan 26 11:56:11 id qmail: 917351771.243102 status: local 0/10 remote
39/40
[...]
Jan 26 11:56:11 id qmail: 917351771.689201 status: local 0/10 remote
38/40
Jan 26 11:56:11 id qmail: 917351771.689736 delivery 7498: deferral:
qmail-remote_crashed./
Jan 26 11:56:11 id qmail: 917351771.690242 status: local 0/10 remote
37/40
qmail-rspawn.c (qmail-1.03):
if (wait_crashed(wstat))
{ substdio_puts(ss,"Zqmail-remote crashed.\n"); return; }
switch(wait_exitcode(wstat))
{
case 0: break;
case 111: substdio_puts(ss,"ZUnable to run qmail-remote.\n");
return;
default: substdio_puts(ss,"DUnable to run qmail-remote.\n"); return;
}
IMHO, the default should be a Z... temporary error as well and specific
errors captured to give a permanent error (i.e. 100). I assume that the
error code here was something from the OS (Redhat Linux 5.1 x86).
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: Unable to run qmail-remote from resource exthaustion PERMENENT error?
On 26-Jan-99 16:06:07, Fred Lindberg wrote something about "Unable to run qmail-remote from resource exthaustion PERMENENT error?". I just couldn't help replying to it, thus: Testing ezmlm stuff on a 486/32MB I ran into some resource exhaustion, and noticed that qmail-remote crashing is a permanent error, while an inability to fork qmail-remote is a permanent error. This seems incorrect and caused loss of a message. Log (the second entry is a crash leading to the expected deferral): Jan 26 11:56:10 id qmail: 917351770.477256 status: local 0/10 remote 40/40 Jan 26 11:56:10 id qmail: 917351770.832994 delivery 7497: failure: Unable_to_run_qmail-remote./ I saw the same thing today. Resource exhaustion (memory) leading to that error message and bounced mail. Not good at all. Regards, /¯¯T¯\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | |If you wake up Sleepy Grumpy, you must be Snow White. |
