From owner-cvs-all  Mon Apr  5 21:33:23 1999
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id E47B714ECE; Mon,  5 Apr 1999 21:33:21 -0700 (PDT)
	(envelope-from peter@FreeBSD.org)
Received: (from peter@localhost)
	by freefall.freebsd.org (8.9.2/8.9.2) id VAA10795;
	Mon, 5 Apr 1999 21:31:24 -0700 (PDT)
	(envelope-from peter@FreeBSD.org)
Message-Id: <199904060431.VAA10795@freefall.freebsd.org>
From: Peter Wemm <peter@FreeBSD.org>
Date: Mon, 5 Apr 1999 21:31:24 -0700 (PDT)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/usr.sbin/cron/cron popen.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

peter       1999/04/05 21:31:24 PDT

  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.
  
  Revision  Changes    Path
  1.6       +10 -1     src/usr.sbin/cron/cron/popen.c


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message