Re: bin/58408: cron ignores parameter "-n" in crontab

[RVP <rvp%SDF.ORG@localhost>]

The following reply was made to PR bin/58408; it has been noted by GNATS.

From: RVP <rvp%SDF.ORG@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: bin/58408: cron ignores parameter "-n" in crontab
Date: Wed, 24 Jul 2024 13:30:46 +0000 (UTC)

 On Wed, 24 Jul 2024, Robert Elz wrote:
 
 >   |  -				while (waitpid(jobpid, &jstatus, WNOHANG) == -1)
 >   |  +				int rc;
 >   |  +				while ((rc = waitpid(jobpid, &jstatus, WNOHANG)) <= 0) {
 >   |  +					if (rc == 0)
 >   |  +						continue;	/* no stat. change */
 >
 >
 > That's not a good idea, that's just turning the nonsense code into
 > a painful busy loop - it might help, but is going to use lots of CPU
 > while doing it.   The real question here is just what WNOHANG is
 > doing there?
 
 Yup (meant to make that change in the final cut).
 
 >   |  -	switch (pid = vfork()) {
 >   |  +	switch (pid = fork()) {
 >
 > If that one makes a difference, something is very broken indeed.
 >
 
 I've never trusted vfork(), and PAM functions are being called
 afterwards (and God knows what _they_ do internally)...  And,
 yeah the mailer processes were being killed properly after that
 change.
 
 > That's attempting to avoid using either unbounded (possibly) memory,
 > or needing to save the output in a temp file.   Whether the mail needs
 > to be sent isn't known until the process completes, and all its output
 > has been sent to cron - it needs to be saved somewhere.  So cron is just
 > assuming that the output is wanted (if MAILTO is set) so opening a
 > connection to the mailer, and sending the process' output as it appears.
 >
 > The pipe buffers and the mailer process manage the storage for that
 > message.
 >
 > When it later discovers that the mail isn't wanted after all, it needs
 > to do something to avoid it being sent.
 >
 
 Yeah I got that the first time around ;) -- just a bit surprised
 is all. I had expected cron to stash the output in a temp file (and
 only if the message exceeded some limit--1MB, say).
 
 
 > I said:
 >
 >     When it later discovers that the mail isn't wanted after all, it needs
 >     to do something to avoid it being sent.
 >
 > That might easily be the problem, if we're talking about a regular
 > user crontab, rather than a root one - the mailer is probably setuid,
 > and the kill attempt might simply be being rejected.
 >
 
 But, that should work on all Unixes, right? (Since the real-uids
 would be the same.) Otherwise, xinit couldn't kill the X server
 when the WM (or whatever) exits.
 
 No, something else is going on because: a) Postfix progs. aren't
 installed set-uid on NetBSD and b) not _every_ successful job run
 is mailed with `-n'. Only some of them are.
 
 I think the stuff in popen.c should be simplified: since cron_popen()
 is only called from one place, it can just return the mailer PID
 too instead of trying to emulate popen(3). Then, you can just kill
 the mailer directly w/o a cron_abort() at all. Gotta see what the
 newer Vixie cron on Github's doing...
 
 Thanks,
 
 -RVP