Copyright 1998 JXH Consulting
This document describes a subsystem so that operations staff can determine its operational state and take limited actions to restore service. See Characteristics of an Operations Interface for the background.
If any test fails, or any problem cannot be corrected, escalate. Document all observations and actions taken.
Sendmail runs as a daemon (-bd) on machines that accept incoming mail. It listens to its well-known port, 25/tcp, and forks children to handle accepted connections. With "-q", it periodically forks a child to deliver queued mail.
Sendmail is controlled by a configuration file, /etc/mail/sendmail.cf.
Mail messages and related control files are stored in /var/spool/mqueue. Each message has an associated queue ID, forming part of the filenames that store each message: df*, qf*, xf*. The queue directory should not be modified manually while sendmail is running, but it may be manipulated as a whole (e.g. moved out of the way) while sendmail is stopped.
Sendmail logs errors and normal deliveries with syslog(3), facility "mail".
# /etc/init.d/sendmail start # /etc/init.d/sendmail stop
On hosts where the daemon is normally running (not all those with sendmail configured), it is started by the link "/etc/rc2.d/S88sendmail".
Check to see that the process is running:
% /bin/ps -ef | /bin/grep sendmail
Several sendmail processes may be running; the daemon is the one whose PPID is 1 (init):
root 168 1 0 May 27 ? 0:02 /usr/lib/sendmail -bd -q1h
^^^^^
Check the syslog(3) for recent sendmail errors, or normal activity messages:
% /bin/tail /var/log/syslog | /bin/grep sendmail
Examine the queue:
% /bin/mailq
A non-empty queue may be normal: some mail may be deferred if destination hosts are down temporarily.
Open a connection to the local sendmail daemon:
% /bin/mconnect localhost quit
Only "220" followed by the hostname is a success. "quit\n" should result in a "221".
Send mail to a user on the local host:
% /bin/mailx -v root Subject: testing sendmail daemon any text ^D EOT
The "-v" should cause delivery progress messages, for example:
root... Connecting to local... root... Sent
Read and delete the message:
# /bin/tail -30 /var/mail/root # /bin/mailx -u root
Sendmail has extensive debugging capabilities, invoked on the command line. Many of the features are directed at debugging configuration files, which are beyond the scope of this operations interface.
The running daemon can be examined at the system-call level with truss(1) but BEWARE slowing down the daemon or generating too much output. Generally, live tracing of a running sendmail daemon should be left to the most experienced sysadmins, but stopping and restarting it may be an appropriate step when it is misbehaving, if the root cause has been corrected.
Start a separate sendmail process to test specific aspects of the environment:
% /usr/lib/sendmail -bv test-address@some.domain.top % /usr/lib/sendmail -v -M#(to force a delivery attempt)
Use gcore(1) to write a core file of the running process without stopping it, or "kill -6" (SIGABRT) to force an exit with core dump. Use adb(1) to begin analysis.
# /bin/gcore -o /var/tmp/core[eof](creates /var/tmp/core. ) -or- # /bin/kill # /bin/kill -6 # /bin/kill -9 # adb /usr/lib/sendmail core. where $q