Hello Matthias, On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote: > For more information, and before replying, please read the thread > http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20201102/002057.html > (even if the Subject: is wrong, because I started with this Subject: > before looking deeper into the process chain and sources).
For what it's worth, by linking to an entire thread, much of which is
not really relevant to a potential Mutt bug, you're making the people
trying to help you do all the work to wade through all the irrelevant
bits and reassemble all the relevant context when we reply. I think
that's bad form. It would be much preferable if you instead posted a
new message that succinctly described what you are doing and how it is
breaking, so we can reply directly to that and quote the relevant
context. That makes more work for you, but you're the one who needs
help, and we are not paid for our time...
That out of the way, a few points:
In the thread, you state:
> El día jueves, noviembre 05, 2020 a las 10:17:25a. m. -0800, Kevin J.
> McCarthy escribió:
> > As far as I know, that mode of operation isn't supported by Mutt. I'm
> > confused how it is working, to be honest. Mutt expects either $sendmail
> > or $smtp_url to be set, and it controls the sending itself.
>
> It *is* supported by mutt using the following trick: one of the arguments
> to mutt is:
>
> .... | mutt -d4 -e "set sendmail=\"cat --\"" ... | sendmail -t
Having to use a hack rather means that it is NOT supported--only that
doing arbitrary other unsupported things with hacks is supported. =8^)
You should not think of Mutt as supporting this--it does not.
> *** 2310,2315 ****
> --- 2310,2317 ----
>
> if (pid != -1 && waitpid (pid, &st, 0) > 0)
> st = WIFEXITED (st) ? WEXITSTATUS (st) : S_ERR; /* return child status
> */
> + else if (errno == ECHILD)
> + st = S_BKG;
> else
> st = S_ERR; /* error */
I agree with Oswald that this is wwrong. I haven't looked at the Mutt
code here yet (well, I have, but not in a very long while) but I hope
to do that tonight. I'm pretty sure I've commented before about
Mutt's child handling code... but it would have been years ago and I
need to refresh the context. From the above snippet, I would also
agree that Mutt's exit status handling is incomplete. That probably
needs to be fixed. I'd need to review the code in more detail to be
confident about whether blocking/ignoring SIGCHLD is appropriate or
not.
Also there's a difference between blocking and ignoring, and that
likely matters. The default disposition of SIGCHLD is to do nothing,
and here, that's not the same thing as SIG_IGN. The latter tells the
OS that the parent doesn't care about its children's exit status (and
won't try to fetch them), so don't save them, which is one way your
program can get ECHILD. Mutt wants the SIG_DFL behavior, and TBH
probably should lose the signal handler entirely. Well-behaved
programs should not use signals whenever there is another way to do
it...
And to address Kevin's comment in that thread:
> Does whatever the server is doing affect the mutt process too,
> despite mutt setting its own handler and blocking SIGCHLD during the
> fork/exec?
No, it does not. Mutt will start with the default signal
dispositions. Signal handler changes are copied across fork(), but
NOT across exec().
Then finally, from this:
> 10502 alarm(0) = 0
> 10502 rt_sigaction(SIGALRM, {sa_handler=0xd76dd3, sa_mask=[],
> sa_flags=SA_RESTORER|0x200, sa_restorer=0x7f9762c035a0}, NULL, 8) = 0
> 10502 kill(10499, SIG_0) = 0
> 10502 exit_group(127) = ?
I conclude that your process chain is exiting only due to a signal
(SIGALRM), which most likely indicates a bug on your end. That
seems to be triggering the bug with Mutt's incomplete child management
code. We have no insight into what your code is doing.
If I had to guess, my guess would be that whatever in your script is
dumping the message to stdout never actually completes; then it's
killed by SIGALRM due to timeout, causing file descriptors to be
closed, which causes sendmail to get EOF, and finally complete sending
the message. That would, in all likelihood, also mean that Mutt is
technically correct--at the time its child dies, the message has in
fact not been sent. It is only sent after the fact, due to the OS
being pretty good at cleaning up messes on behalf of user programs.
But that time delta is so small that it's hard for the humans to
notice the difference.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
signature.asc
Description: PGP signature
