On Sun, 2006-12-03 at 11:59 -0500, Francisco Reyes wrote:
Timo Sirainen writes:
So there are two solutions for this:
- Change all Dovecot's exit codes to use the standard exit codes.
What advantage, if any, is there to the current return codes that postfix doesn't udnerstand?
The current exit codes were implemented to Dovecot long before deliver even existed. But there are also some advantages. Dovecot's exit codes are:
FATAL_LOGOPEN = 80, /* Can't open log file */
FATAL_LOGWRITE = 81, /* Can't write to log file */
FATAL_LOGERROR = 82, /* Internal logging error */
FATAL_OUTOFMEM = 83, /* Out of memory */
FATAL_EXEC = 84, /* exec() failed */
FATAL_DEFAULT = 89Normally all the exit codes are the FATAL_DEFAULT. In these cases Dovecot also logs the actual error message. The other codes are useful, because if any of them happens there might not be any error messages in logs, so the only way to know what happened would be to look at the exit code (which Dovecot master logs, if it can).
If I used the standard exit codes, the first 5 would be:
#define EX_OSERR 71 /* system error (e.g., can't fork) */
And the default exit code would probably be:
#define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
If EX_OSERR happens and there's nothing in the logs, there's really no way to know if the error happened because the log couldn't be written to or because memory was low.
I'm not sure why I've added FATAL_EXEC. If it happens there should also be a proper error logged.
Both of these are pretty large changes, so they won't happen before v1.0..
I used a third solution... changed to use syslog.
Well, yes, this fixes your particular problem. But there are also other rare problems which should be treated as temporary errors instead of permanent errors.
I would have preferred to use the logs since it breaks down into informative and error outputs, but bouncing mail is not good.. just because it could not connect to logs.
Shouldn't the problem also go away if you just fix it so that deliver can always write to the logs?..