On Thu, Nov 12, 2020 at 12:18:07PM +0100, Oswald Buddenhagen wrote: > On Thu, Nov 12, 2020 at 10:31:59AM +0100, Matthias Apitz wrote: > > El día miércoles, noviembre 11, 2020 a las 02:34:57p. m. -0600, Derek > > Martin escribió: > > > > > 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.
No one said anything about it being illegal. Mutt encourages hacks.
Mutt doesn't DIRECTLY support using sendmail this way. You had to
write glue to make it work, even if that glue was just a cat command
line--which it wasn't, you actually had to write an external program
to do what you're doing. Either way, that makes it a hack, by
definition. But that doesn't make what you're doing "supported"--it
only makes it POSSIBLE. Caveat emptor.
> that seems to be a common theme in your thinking. ;-) just because
> something is possible and not explicitly forbidden doesn't mean it's
> a good idea. with this hack you have no error checking at all, and
> unexpected output on stdout would mess up things totally.
Agree, although I'm not sure about that last bit... Mutt closes all
file descriptors (except stdin) before executing sendmail, some of the
time. I didn't trace out exactly when. When it does, that should be
impossible. When it doesn't... I don't think we have enough info
about what/where stdout is. It's possible that it's a pipe to one of
the other processes in the process pipeline. If nothing is reading
it, the script may be blocked trying to write to stdout. Or some
such. But there's a fair likelihood given how it's running that it's
already /dev/null.
> > 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
> >
> there is no excuse whatsoever for spawning a child with suppressed sigchld
> (same for *most* other signals, for that matter). if this is indeed what is
> happening, you have your root cause right there (and my assessment from the
> other mail was in fact incorrect).
Agree.
> > (with good reasons,
> >
> nonsense.
Agree.
> > because all the error handling should be done within "script" and not by
> > the application server, which has to serve Java written GUI frontends).
> >
> that might be true, but is no excuse for ignoring errors that still come
> through, and even more for actively interfering with the child's execution
> environment.
Agree.
So I got this pretty wrong too, and admittedly didn't spend enough
time trying to understand some of the pieces.
One point that is not clear to me is, the sigaction manpage explicitly
calls out execve, rather than the whole exec family. It seems to
suggest that execvp (which is what mutt is using to spawn the sendmail
process) doesn't do that. It could be a case of the man page being
incorrectly overly specific, or just out of date... Or it could be
that we still haven't nailed down the exact cause of Matthias'
problem.
Regardless, normally Mutt calls mutt_signal_init() which explicitly
sets the disposition of SIGCHLD, avoiding the above behavior. However
run in a pipe as Matthias is doing here, it does not do that. While I
think it's fair to say no developer ever anticipated this happening
for good reason, perhaps it makes sense for Mutt to unconditionally
reset the disposition of ALL signals to default before it does much of
anything else, to keep people from abusing it this way. But better
yet, just Don't Do That™.
I believe the rest of what I said about Mutt's handling of SIGCHLD,
its mishandling of waitpid(), and the negative consequences of the
double fork remain true, and are things that probably should be fixed.
However it's a fair amount of work, for a relatively small payoff of
correctness (disambiguated error conditions, but error conditions
nonethess), which the overwhelming majority of users will probably
never notice, and that's somewhat likely to introduce new bugs. It's
work that probably no one should be eager to do, at least without a
willingness to spend ample time testing around the sendmail bits and
around ALL the waitpid calls. Probably should just be kept in mind
for future cases like this one.
--
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
