🚀 go-pugleaf

"Bad file number" means that sendmail blew it and overwrote errno (which
contained the reason the mail failed on the last attempt) with EBADF before
recording the error in the envelope of the message.

EBADF is a common error in the several utility functions sendmail calls
while it is logging a message delivery failure. There's nothing to be done.
On the next try you may get lucky and get a better message (or even luckier
the message may get delivered :-).

Often you'll see the 'bad file number' when the smtp socket closed
unexpectedly.  Most often around here we see it when the connection to
the host timed out while sendmail was doing a read on the socket - I
have the read timeout set short to keep large numbers of sendmails from
sitting idly by gasping in hope that yet another byte will be received
across the internet.  Occasionally you'll see it when the distant
mailer (sendmail or another) died for some reason and reset the
connection.

Most of these are transient problems.  If you keep seeing it,
especially when it is repeated on a specific piece of mail, it may be an
indication of an underlying mail or network problem.

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA

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