[lsb-discuss] Clarification of general LSB requirements

Aaron Sowry aeneby at gmail.com
Wed Jul 10 14:00:55 UTC 2013


On Wed, 2013-07-10 at 08:41 -0400, Jeff Licquia wrote:
> "Sensible" behavior from the sendmail utility in a situation where /var
> is full, for example, is not even remotely guaranteed, given that a
> number of MTAs put their active mail queue in /var.

"Sensible" behaviour does not mean guaranteeing delivery. Again,
sendmail can't guarantee anything. In the case of /var being full,
exiting non-zero would be perfectly sensible behaviour, since there was
in fact an error. If a full /var is not something which sendmail can
detect itself, then even exiting 0 would be sensible.

> And--looking at the spec, not necessarily implemented behavior--I don't
> see any difference at all that an app can tell between an app calling
> sendmail on a system with /var full and an app calling lsb-invalid-mta's
> sendmail.  (Perhaps there should be, but that's a different conversation.)

The spec says that all exit codes >0 are an error, but there's nothing
to say that all non-zero exit codes are therefore undefined. Even if we
assume that all non-zero exit codes *are* undefined, there are still
important differences between the two cases. How do I know not to bother
retrying in the case of lsb-invalid-mta's error, for example? A
full /var is not the only error that can occur, and many errors are
temporary.

> My point is that apps are required by the spec to handle the former
> case, which means they are also required to handle the latter, and that
> there is no difference in code between the two.

You're technically correct, but I don't agree with your conclusion. You
seem to be saying that since it's possible for sendmail to fail
*sometimes*, then it must be okay for it to fail *all* the time. Yes,
applications should be able to handle both cases, but there are crucial
differences between failing because something actually went wrong and
failing by design.



More information about the lsb-discuss mailing list