This is a hack. Cron runs with stdin/out/err pointing to /dev/console,

which init thoughtfully revoke()'s when starting a getty on ttyv0.  This
Cron's popen() was passing these fd's through to cron children (ie:
sendmail, *not* normal cron jobs).  The side effects were usually
not noticed, but it tripped up postfix which did a sanity check to see
that stdin/out/err were open, and got EBADF even thought the fd's were
in use.  I seem to recall sendmail itself has hacks to work around
this problem, it had a checkfd012() function, possibly for this same
problem.  (Postfix has a workaround too now though..)

This is a hack, not a fix.  It's probably best to check and perhaps
close/reopen() /dev/console if needed each time around the event loop.
It would probably be useful to actually see any error messages from cron.
This commit is contained in:
Peter Wemm 1999-04-06 04:31:23 +00:00
parent 964462c09d
commit 5ef4895832
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=45369

View File

@ -28,11 +28,12 @@
static char sccsid[] = "@(#)popen.c 5.7 (Berkeley) 2/14/89";
#endif
static const char rcsid[] =
"$Id$";
"$Id: popen.c,v 1.5 1997/09/15 06:39:07 charnier Exp $";
#endif /* not lint */
#include "cron.h"
#include <sys/signal.h>
#include <fcntl.h>
#define MAX_ARGS 100
@ -105,6 +106,9 @@ cron_popen(program, type)
/* NOTREACHED */
case 0: /* child */
if (*type == 'r') {
/* Do not share our parent's stdin */
(void)close(0);
(void)open("/dev/null", O_RDWR);
if (pdes[1] != 1) {
dup2(pdes[1], 1);
dup2(pdes[1], 2); /* stderr, too! */
@ -116,6 +120,11 @@ cron_popen(program, type)
dup2(pdes[0], 0);
(void)close(pdes[0]);
}
/* Hack: stdout gets revoked */
(void)close(1);
(void)open("/dev/null", O_RDWR);
(void)close(2);
(void)open("/dev/null", O_RDWR);
(void)close(pdes[1]);
}
#if WANT_GLOBBING