From owner-cvs-all Tue Apr 6 10:11:27 1999 Delivered-To: cvs-all@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id A366315671; Tue, 6 Apr 1999 10:11:20 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.3/8.9.3/Netplex) with ESMTP id BAA00798; Wed, 7 Apr 1999 01:07:52 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199904061707.BAA00798@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian Somers Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/cron/cron popen.c In-reply-to: Your message of "Tue, 06 Apr 1999 08:56:17 +0100." <199904060756.IAA74128@keep.lan.Awfulhak.org> Date: Wed, 07 Apr 1999 01:07:52 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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