Hello Derek et all,
El día miércoles, noviembre 11, 2020 a las 02:34:57p. m. -0600, Derek Martin escribió: > 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... You're correct, esp. as the thread started with a later invalid subject. I should have assembled a new description of the problem. Please accept my excuse for this. Thanks for all your comments, even if I disagree in parts. > > 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. This is not a hack. The Mutt variable $sendmail is meant to specify any process as MTA. Mutt is piping its output into the specified UNIX proc and adds as arguments mail address(es) which we ignore in our case, because the mail addr is specified in the mail itself as To: header. I can not see that using cat(1) as MTA and writing the message to STDOUT is some kind of (illegal) hack. > > > *** 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. ... Until now, nobody has said *what* is wrong with the handling of ECHILD here. The man page for wait(2) clearly says why this ECHILD can happen: ECHILD (for waitpid() or waitid()) The process specified by pid (waitpid()) or idtype and id (waitid()) does not exist or is not a child of the calling process. (This can happen for one's own child if the action for SIGCHLD is set to SIG_IGN. See also the Linux Notes section about threads.) I'm already debugging our own application server which starts the shell script creating all this process chain with system("script") and I *think* this has set SIGCHLD to SIG_IGN (with good reasons, because all the error handling should be done within "script" and not by the application server, which has to serve Java written GUI frontends). And I *think* that this disposition of SIGCHLD is also inherit to the Mutt proc and the proc chain behind it. Because, when I start the script on the cmd line with an prepared file 'mail.txt' containing To: and other header lines like: $ script < mail.txt | /usr/lib/sendmail -t this ECHILD situation does not occur. > 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(). I will debug this and let you know if this is true or not. > 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. Completely wrong. The above straced sys calls are the C-code in Mutt itself: sendlib.c, around line 2295 (from 1.18.3 version): ... /* reset alarm; not really needed, but... */ alarm (0); sigaction (SIGALRM, &oldalrm, NULL); if (kill (ppid, 0) == -1 && errno == ESRCH && tempfile && *tempfile) { /* the parent is already dead */ unlink (*tempfile); FREE (tempfile); /* __FREE_CHECKED__ */ } _exit (st); } And there is no SIGLARM occurring in all this straced proc chain: If you interrupt some proc with SIGALARM, this looks in strace like this (a small C pgm calling alarm(5) and sleep(10)): $ strace ./a.out ... alarm(5) = 0 nanosleep({tv_sec=10, tv_nsec=0}, {tv_sec=5, tv_nsec=45334}) = ? ERESTART_RESTARTBLOCK (Interrupted by signal) --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} --- +++ killed by SIGALRM +++ Alarm clock In my traces of the Mutt proc chain there is no SIGALRM arriving at all: $ grep SIGAL /tmp/mutt.tr.24681 24712 rt_sigaction(SIGALRM, {sa_handler=0x4c5703, sa_mask=[], sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7fb4634995a0}, <unfinished ...> 24712 rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb4634995a0}, NULL, 8) = 0 24712 rt_sigaction(SIGALRM, {sa_handler=0x4c5703, sa_mask=[], sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7fb4634995a0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb4634995a0}, 8) = 0 24712 rt_sigaction(SIGALRM, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb4634995a0}, NULL, 8) = 0 24715 rt_sigaction(SIGALRM, {sa_handler=0x1d7ddd3, sa_mask=[], sa_flags=SA_RESTORER|0x200, sa_restorer=0x7fb4634995a0}, NULL, 8) = 0 To summarize for the moment: The code of Mutt is lacking a proper handling of the ECHILD as result of waitpid(). You can say that my proposal is wrong, of course, but then please come up with a better/correct one. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub Без книги нет знания, без знания нет коммунизма (Влaдимир Ильич Ленин) Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)
