In past releases of sendmail, changes in file descriptors and other key variables have sometimes occurred for reasons that remain a mystery to this day. Small "sanity checks" have been included in the code to discover such anomalies, should they happen again. To exclude these checks, redefine XDEBUG to 0:

APPENDDEF(`confENVDEF', `-DXDEBUG=0')

Generally, however, XDEBUG should always remain enabled. It adds only a microscopic amount of overhead to sendmail and helps to certify sendmail's rational behavior.

If sendmail's notion of who it is (as defined by the $j defined-macro, $j) gets trashed by losing all its dots, sendmail will log the following at LOG_ALERT if XDEBUG is defined, dump its state (SIGUSR1), and abort(3):

daemon process $j lost dot; see syslog

At startup the value in the $j defined-macro ($j) is added to the class w ($=w). If sendmail is compiled with XDEBUG, it periodically checks to make sure that $j is still listed in class w. If $j should vanish, sendmail will log the following at LOG_ALERT, dump its state (SIGUSR1), and abort(3):

daemon process doesn't have $j in $=w; see syslog

With XDEBUG defined, sendmail periodically checks to see whether its standard I/O file descriptors have gotten clobbered. If so, it logs the following and tries to recover by connecting it to /dev/null:

where: fd  which  not open

Here, where will reflect the internal subroutine name and arguments that led to the check, and which will be the bad file descriptor number.

If you are running a precompiled sendmail binary, you can use the -d0.1 debugging command-line switch (-d0.1) to determine if XDEBUG support is included (if it appears in the list, support is included).