I was able to convince campus security to let me into the building so I could
dump/reboot/crash/dump/reboot my sendmail porting machine.
It seems that I have re-encountered the same "fork() of death" problem that I
reported for BIND/iX many months ago. The parent process is waiting for the
fork() to complete, and the child process is in the middle of inheriting
all of the parent's open file descriptors when it encounters a problem and
aborts with interrupts disabled, resulting in system abort 1458 from
subsystem 102.
In the case of BIND/iX, the apparent cause was using fcntl() instead of
sfcntl() to F_DUPFD socket descriptors. Sendmail/iX doesn't F_DUPFD, but
does F_GETFD and F_SETFD instead, plus dup() and dup2().
Unfortunately, these fcntl() calls are deep in generic subroutines that don't
always know if the descriptor is a socket descriptor (must call sfcntl) or
a regular file descriptor (must call fcntl).
So I need a way to determine whether a generic file descriptor of unknown
origin is either a normal file descriptor or really a socket descriptor.
After some playing around, I came up with something like this:
if (fstat(fd,&statbuf) == -1 && errno == ESYSERR) {
sfcntl(fd, ...) /* it's a socket descriptor */
} else {
fcntl(fd, ...) /* it's a normal file descriptor */
}
On some Unixes, statbuf.st_mode would contain a special file type for a socket,
but MPE doesn't, and indeed the fstat() just fails totally with ESYSERR.
Is there a better test I could be doing here? It bothers me to check for
ESYSERR, because I don't know if fstat() could also return this for a non-socket
in some bizarre situation.
PS: The good news is that when the machine doesn't crash, I am able to
successfully send and receive e-mail. :-)
--
Mark Bixby E-mail: [log in to unmask]
Coast Community College Dist. Web: http://www.cccd.edu/~markb/
District Information Services 1370 Adams Ave, Costa Mesa, CA, USA 92626-5429
Technical Support Voice: +1 714 438-4647
"You can tune a file system, but you can't tune a fish." - tunefs(1M)
|
