Date: Wed, 07 Apr 1999 01:07:52 +0800 From: Peter Wemm <peter@netplex.com.au> To: Brian Somers <brian@Awfulhak.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/cron/cron popen.c Message-ID: <199904061707.BAA00798@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 06 Apr 1999 08:56:17 %2B0100." <199904060756.IAA74128@keep.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Somers wrote:
> > Modified files:
> > usr.sbin/cron/cron popen.c
> > Log:
> > 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 isn't really correct either though. The descriptors could be
> revoked after cron execs. I would have thought there should be some
> way of revoking a terminals session and process group ids, resulting
> in the disassociation of all controlling processes, but *not* the
> revoke()ing of any descriptors. It could be used in place of
> revoke() for /dev/console (maybe settable in /etc/ttys).
These fd's are not passed onto the cron *jobs* (I mentioned this above).
The only thing that cron uses this popen for is to send the output mail to
the user. It (cron) has tries to log critical events to those fd's when
syslog fails (for example), and happens to pass stderr to /dev/console to
sendmail, so that when sendmail prints "foo.. user unknown" to stderr it
actually goes somewhere. It's trying to keep stderr open as a 'last gasp'
error reporting destination.
Actual *jobs* run from /etc/crontab and user crontabs are done via an
entirely different mechanism and are unaffected by this stuff.
Maybe it could open a reverse pipe back from sendmail and collect any error
messages and then syslog() the gathered strings, but that hardly seems
worthwhile.
What I'd like to know though, is why a fd to /dev/console gets revoked
when something does a revoke("/dev/ttyv0") - they have different minor/major
numbers and you can see the difference between the two via ps. I'd have
thought that fd's to /dev/console should never be revoked...
Cheers,
-Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904061707.BAA00798>