what does "deferral: qmail-local_crashed./" mean?

[Shaya Potter]

I see it a lot in my logs.  What does it mean?  should I just ignore it
or if it matters, how do I debug it?

googling it, didn't give me much.

thanks.

shaya

[Charles Cazabon]

Shaya Potter <spotter@...> wrote:
> I see ["deferral: qmail-local_crashed./"] a lot in my logs.  What does it
> mean?

Oddly enough, it means that qmail-local crashed, and that the local delivery
has therefore been deferred -- i.e., qmail will try again in a little while to
deliver the message.

> should I just ignore it or if it matters, how do I debug it?

The first step would be to figure out if it's random or not.  i.e., is it
always deliveries to a particular local address that crash, or is it random?

Charles
--
--------------------------------------------------------------------------
Charles Cazabon                               <qmail@...>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting.  See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

[Shaya Potter]

Charles Cazabon wrote:

> Shaya Potter <spotter@...> wrote:
>> I see ["deferral: qmail-local_crashed./"] a lot in my logs.  What does it
>> mean?
>
> Oddly enough, it means that qmail-local crashed, and that the local delivery
> has therefore been deferred -- i.e., qmail will try again in a little while to
> deliver the message.
>
>> should I just ignore it or if it matters, how do I debug it?
>
> The first step would be to figure out if it's random or not.  i.e., is it
> always deliveries to a particular local address that crash, or is it random?

with some off list help i figured it out, it was due to a bad syntaxed
.qmail-default file of one of my users.  (they were trying to junk all
mail to a specific alias, and did #|/bin/true instead of |/bin/true)

thanks.

[Charles Cazabon]

Shaya Potter <spotter@...> wrote:
>
> with some off list help i figured it out, it was due to a bad syntaxed
> .qmail-default file of one of my users.  (they were trying to junk all mail
> to a specific alias, and did #|/bin/true instead of |/bin/true)

They should instead just put "#" in the relevant .qmail file.

Charles
--
--------------------------------------------------------------------------
Charles Cazabon                               <qmail@...>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting.  See http://pyropus.ca/ for details.
--------------------------------------------------------------------------

[Harald Hanche-Olsen]

+ Charles Cazabon <qmail@...>:

| Shaya Potter <spotter@...> wrote:
| >
| > with some off list help i figured it out, it was due to a bad syntaxed
| > .qmail-default file of one of my users.  (they were trying to junk all mail
| > to a specific alias, and did #|/bin/true instead of |/bin/true)
|
| They should instead just put "#" in the relevant .qmail file.

That they should, but "#|/bin/true" is actually quite close to that.
It's a valid comment after all, and should not have crashed
qmail-local.  Really, qmail-local should be really hard to crash.

- Harald

[Matt Simpson-2]

At 8:49 AM 4/19/07, Charles Cazabon wrote:
>Shaya Potter <spotter@...> wrote:
>  >  (they were trying to junk all mail
>  > to a specific alias, and did #|/bin/true instead of |/bin/true)
>
>They should instead just put "#" in the relevant .qmail file.

What's the difference between
# and #|/bin/true  (or #anyrandomcharacters)?

Isn't any line beginning with # considered a comment?

(I realize that #|/bin/true is probably an indication that they were
trying to do something they didn't need to, and # would be more
straightforward.  I just don't see why anything following the # would
cause a crash).

[Shaya Potter]

Matt Simpson wrote:

> At 8:49 AM 4/19/07, Charles Cazabon wrote:
>> Shaya Potter <spotter@...> wrote:
>>  >  (they were trying to junk all mail
>>  > to a specific alias, and did #|/bin/true instead of |/bin/true)
>>
>> They should instead just put "#" in the relevant .qmail file.
>
> What's the difference between
> # and #|/bin/true  (or #anyrandomcharacters)?
>
> Isn't any line beginning with # considered a comment?
>
> (I realize that #|/bin/true is probably an indication that they were
> trying to do something they didn't need to, and # would be more
> straightforward.  I just don't see why anything following the # would
> cause a crash).

you're right, it was not that.

the original file also output to a file as well as the /bin/true line.

that file's permissions made it unwritable to qmail which caused the crash.

[Harald Hanche-Olsen]

+ Shaya Potter <spotter@...>:

| that file's permissions made it unwritable to qmail which caused the crash.

But even that should not cause a crash.  The relevant code is in
qmail-local.c, in function mailfile():

 fd = open_append(fn);
 if (fd == -1)
   strerr_die5x(111,"Unable to open ",fn,": ",error_str(errno),". (#4.2.1)");

So you should see the message "Unable to open ...: . (#4.2.1)".

Something tells me that your qmail installation or OS is broken.

- Harald

[Uncle George]

I think that it would be better to replicate scenario in-house. Then
claim others-at-fault.

Can user issue be recreated, and then the steps posted on-line?

Harald Hanche-Olsen wrote:

> + Shaya Potter <spotter@...>:
>
> | that file's permissions made it unwritable to qmail which caused the crash.
>
> But even that should not cause a crash.  The relevant code is in
> qmail-local.c, in function mailfile():
>
>  fd = open_append(fn);
>  if (fd == -1)
>    strerr_die5x(111,"Unable to open ",fn,": ",error_str(errno),". (#4.2.1)");
>
> So you should see the message "Unable to open ...: . (#4.2.1)".
>
> Something tells me that your qmail installation or OS is broken.
>
> - Harald
>
>

[Harald Hanche-Olsen]

+ "U. George" <qmail@...>:

| I think that it would be better to replicate scenario in-house. Then
| claim others-at-fault.
|
| Can user issue be recreated, and then the steps posted on-line?

You mean like this?
(Replace USER by your username, mailhost.example.com by your hostname.)

; echo ./Mailbox-foo > .qmail-foo
; touch ./Mailbox-foo
; chmod 400 ./Mailbox-foo
; echo foo |
  /var/qmail/bin/mailsubj 'Unreadable test' USER-foo@...

With these results in the log (timestamps elided):

starting delivery 9328: msg 973272 to local USER-foo@...
delivery 9328: deferral: Unable_to_open_./Mailbox-foo:_access_denied._(#4.2.1)/

You might get a different result if the file looks writable, but
really is not.  For example, it could have the right mode but reside
on a read-only filesystem.

To clean up:

; chmod 600 ./Mailbox-foo
# wait for the message to be delivered, then
; rm ./Mailbox-foo .qmail-foo

- Harald

[Uncle George]

Not your example, as that does not crash.

The actual file, and conditions, that would cause the problem. Presuming
that the user can condition it to break again.

Harald Hanche-Olsen wrote:

>
> You mean like this?
> (Replace USER by your username, mailhost.example.com by your hostname.)

[Harald Hanche-Olsen]

+ Shaya Potter <spotter@...>:

| Again, my analysis was wrong :)
|
| think it was file size
|
| $ ls -lh Mailbox-default-sas
| -rw------- 1 shmuelp users 2.0G 2006-12-16 00:45 /home/shmuelp/Mailbox-default-sas

A 2 gigabyte mbox?  The mind boggles.

| my gut feeling is that this is perhaps because qmail is not using
| large file support?

Yeah, you're probably right.  qmail-local checks the file position
before it starts writing, so that it can truncate the file back to
where it was if it needs to interrupt what it's doing.  And that code
is strictly 32-bit, IIRC.

- Harald

[Shaya Potter]

Harald Hanche-Olsen wrote:

> + Shaya Potter <spotter@...>:
>
> | Again, my analysis was wrong :)
> |
> | think it was file size
> |
> | $ ls -lh Mailbox-default-sas
> | -rw------- 1 shmuelp users 2.0G 2006-12-16 00:45 /home/shmuelp/Mailbox-default-sas
>
> A 2 gigabyte mbox?  The mind boggles.

yea, basically it was a spam trap that the person has seemingly forgot
about.

> | my gut feeling is that this is perhaps because qmail is not using
> | large file support?
>
> Yeah, you're probably right.  qmail-local checks the file position
> before it starts writing, so that it can truncate the file back to
> where it was if it needs to interrupt what it's doing.  And that code
> is strictly 32-bit, IIRC.

bug in qmail or "user is the bug for letting it grow that big" :)