+ Fred Backman <[EMAIL PROTECTED]>:
| Here are the results of strace/truss on a qmail-lspawn session which
| caused qmail v1.00 to crash on Linux RH 5.2. Apologies for the long
| post.
The length is not a big problem. The fact that the traces came from a
patched version of qmail 1.00 is a bigger problem - you are not likely
to get very much specific help.
| Here's what I did:
| 0. Emptied the queue.
| 1. Restarted qmail
| 3. Started "strace -f -p 2074" in one window [qmail-send pid]
| 4. Started "strace -f -p 2076" in another window [qmail-lspawn pid]
| 5. Ran "echo to:fred|/var/qmail/bin/qmail-inject" in a third window
|
| After that, qmail crashed. But the message had been delivered
| locally to fred's Maildir/new directory, _and_ the very same message
| was still in the queue!
Yes, indeed. From your traces I notice some oddities - starting with
the qmail-lspawn trace, here showing the qmail-alias process:
| [pid 2086] link("tmp/927231667.2086.localhost.localdomain",
| "new/927231667.2086.localhost.localdomain") = 0
| [pid 2086] unlink("tmp/927231667.2086.localhost.localdomain") = 0
| [pid 2086] _exit(0) = ?
That is the qmail-alias child process correctly managing a maildir
delivery, but still, the parent writes this log entry:
| [pid 2085] write(1, "did 0+0+0\n", 10) = 10
That is not a likely cause of your problem, but something to look
into: Surely, it should have been "did 1+0+0\n"?
Your qmail-send trace is more interesting. It shows qmail-send
detecting a pending bounce for message 313551, then setting up pipes
and forking, the child trying but failing to run qmail-queue in order
to inject the bounce message. You should look at the permissions on
qmail-queue (should be -rws--x--x I think). But what is really odd is
that qmail-send (the parent) segfaults, apparently even before the
child exits (even before it has started writing any data to the pipe).
If you fix the permission problem with qmail-queue, maybe this other
problem goes away.
Summary:
- Make sure qmail-queue has the right permissions.
- Look at your patches with a great dose of skeptisism.
- Perhaps worry about the fork vs vfork issue
(about which I know next to nothing, but if problems in child
process interfere with the parent, I would suspect vfork (but fork
and vfork are the same on at least some systems)).
- If all fails, maybe abandon your patches and move to qmail 1.03.
- Harald
