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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/58408: cron ignores parameter "-n" in crontab
Date: Wed, 24 Jul 2024 18:05:00 +0700

     Date:        Wed, 24 Jul 2024 09:45:01 +0000 (UTC)
     From:        RVP <rvp%SDF.ORG@localhost>
     Message-ID:  <20240724094501.EADC31A923C%mollari.NetBSD.org@localhost>
 
 
   |  -				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?   That looks like it might have been added as a generic
 (always set that flag) rather than for anything useful.  Remove that
 and there won't be a 0 return possible, so the rest of the change would
 be a no-op.
 
   |  -	switch (pid = vfork()) {
   |  +	switch (pid = fork()) {
 
 If that one makes a difference, something is very broken indeed.
 
   |  In addition to mailing on success (with -n), cron doesn't seem to
   |  kill the mailer process properly either. (I didn't realize 'til
   |  now how cron worked for `-n' in crontab: Without the `-n', cron
   |  reads the output of the job, then runs a mailer process and writes
   |  the output to it. If you add `-n' it does _the same_ thing, then
   |  instead of closing the pipe on EOF, _kills_ the mailer process.
   |  This aborts the sending of the collected mail data--a _very_ odd
   |  way to do things...)
 
 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.
 
 kre