Date: Mon, 22 Mar 1999 14:14:40 +0800 From: Peter Wemm <peter@netplex.com.au> Subject: Re: cron problem? Message-ID: <199903220614.OAA53446@spinner.netplex.com.au>
next in thread | raw e-mail | index | archive | help
------- Blind-Carbon-Copy
X-Mailer: exmh version 2.0.2 2/24/98
To: postfix-users@postfix.org (Postfix Users List)
Subject: Re: cron problem?
In-reply-to: Your message of "Sun, 21 Mar 1999 18:33:02 EST."
<m10OriI-000g60C@most.weird.com>
Date: Mon, 22 Mar 1999 14:14:40 +0800
From: Peter Wemm <peter@spinner.netplex.com.au>
Greg A. Woods@planix.com (Greg A. Woods) wrote:
> [ On Sunday, March 21, 1999 at 17:45:00 (-0500), Wietse Venema wrote: ]
> > Subject: Re: cron problem?
> >
> > Jon Ribbens:
> > > The idea was that your code was assuming that fstat() never returns -1
> > > when the descriptor is open, that appears to be wrong in some cases
> > > as has been discovered, so maybe it is best to abandon that assumption.
> >
> > No. Only a broken fstat() fails on an open file descriptor.
>
> Indeed. Fstat() should work on any file descriptor that can be
> successfully passed to close().
I've been having a head scratch tring to understand WTF is going on.
It seems... that cron is running with stdin/stdout/stderr pointing off
into the void. They appear to have once been attached to /dev/console but
have been revoke(2)ed by init when the getty starts on the console.
Basically revoke() disconnects fd's that point to the given vnode and
reattaches them to the "deadfs" filesystem that just returns errors to
everything, including (as it happens) fstat(2) which gets an EBADF.
208> fstat | grep cron
root cron 184 root / 2 drwxr-xr-x 1024 r
root cron 184 wd /var 3 drwxr-x--- 512 r
root cron 184 text /usr 32064 -r-xr-xr-x 24876 r
root cron 184 0 - - none -
root cron 184 1 - - none -
root cron 184 2 - - none -
root cron 184 3 /var 28822 -rw-r--r-- 4 rw
root cron 184 4* local dgram c6b0bf40 <-> c6b0afc0
fd's 0, 1 and 2 point off to "none" aka deadfs. (fd 3 is it's pid file, fd
4 is a socket to syslog).
Sigh. Call this a quirk of the BSD init system, combined with a quirk of
the /dev/console redirector, which is interacting with revoke(), which cron
doesn't check for, which is breaking postfix. :-)
Daemons are started with write access to /dev/console, and then at some
point later, it's removed. The interesting thing is that there is no actual
getty on /dev/console in my case, it's on /dev/ttyv0 which is a different
device. It seems revoke() is killing /dev/console users as a side effect
of zapping /dev/ttyv0 strays. Hmm...
In any case, cron should NOT be passing this sort of environment to it's
children. Normal cron jobs don't see this as they get their own stdin/out/
err etc, but the hacked popen() that vixie-cron uses resets stdin for the
sendmail call, but not stdout/stderr.
Double-sigh. revoke(2) is the cause of fstat() failing on an open fd.
Cheers,
- -Peter
------- End of Blind-Carbon-Copy
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903220614.OAA53446>