Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!nbires!isis!udenva!cu-den!boulder!sunybcs!rutgers!clyde!cbosgd!osu-cis!tut!tut.cis.ohio-state.edu!mumble@karl
From: karl@mumble.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: comp.mail.misc
Subject: Re: mailq output
Message-ID: <980@tut.cis.ohio-state.edu>
Date: Wed, 4-Nov-87 08:00:14 EST
Article-I.D.: tut.980
Posted: Wed Nov  4 08:00:14 1987
Date-Received: Sun, 8-Nov-87 11:29:28 EST
References: <619@hubcap.UUCP>
Sender: news@tut.cis.ohio-state.edu
Reply-To: karl@tut.cis.ohio-state.edu
Lines: 27
In-reply-to: hubcap@hubcap.UUCP's message of 3 Nov 87 14:51:28 GMT


hubcap@hubcap.UUCP writes:
   I need some help deciphering the following output from mailq:
   AA19170*    1359 Mon Nov  2 22:10 rajgl
				     (Deferred: Bad file number)
				     hirani@sushi.stanford.edu
   Bad file number? Where is this number? What do I do to turn it into
   a "good" file number?

"Bad file number" is the error string associated with a read() or
write() returning EBADF.  What has happened is that, during a
connection with sushi.stanford.edu, sushi closed down the connection.
Your kernel noticed this fact and obliterated the file descriptor
internally, but sendmail didn't know it right away.  When it next
tried to read() or write() to the file descriptor which it thought was
still connecting it with sushi, the kernel responded with -1 and
EBADF.  No problem - the next time sendmail runs the queue, it'll try
to connect with sushi again.

In fact, note that there's a `*' next to the mailq job number, which
means that sendmail is working on that job at the current time.  So
the EBADF indicator is from the *previous* time that the connection to
sushi was attempted.  If the same trouble happens again, the same
error message will be re-asserted in the qfAA19170 file, otherwise,
the mail will move to sushi successfully, or some other error message
will replace the EBADF indicator.
-=-
Karl