The Sendmail Boot-Hang & More

Updated 18 October 1997


Disclaimer: I am not a sendmail expert. I've managed to get things working nicely on my system and I've poked around a little for information, and that's all. You have been warned: if you try my suggestions and they don't work, I won't take the blame (but please e-mail me - gmfall.engin.umich.edu - if it happens). Finally, this document assumes that you have a PPP connection to your ISP configured and running successfully.

This is a common problem folks have: they're sitting there watching Linux boot up, everything is going fine, then the screen says

Starting sendmail: sendmail

and sits there for like 30 seconds, maybe more, before moving on. This comes up rather often on the redhat-list mailing list, and there are a range of solutions proposed, all pretty much more or less the same. I'll give the basic solution here, which will be accompanied by a sort of primer on what a regular old PC owner needs to do to make sendmail behave properly for him/herself and anybody else in the house that wants to be able to send and receive e-mail. If you want to use Red Hat's control-panel tools rather than directly editing the appropriate files, netcfg ("Network Configuration" in the control panel) can be used to do most of the editing suggested here.

First, the short answer. If your /etc/hosts file (or the "Hosts" section in netcfg) lists the loopback address (127.0.0.1, your computer's IP address when it is talking to itself) as having only a name that is an unqualified domain name - something like pinky - you will experience the sendmail hang. If localhost and/or a fully-qualified domain name (FQDN), is listed, your system will not hang.

Now the long answer. When sendmail starts, it attempts to find values for different macros - special variables internal to sendmail. I'll quote the Sendmail Installation and Operation Guide, which Red Hat systems should have in Postscript form in /usr/doc/sendmail/doc/op/op.ps (it is part of the sendmail-doc RPM package):

The macros $w, $j, and $m are set to the identity of this host. Sendmail tries to find the fully qualified name of the host if at all possible; it does this by calling gethostname(2) [a standard C library function] to get the current hostname and then passing that to gethostbyname(3) [another library function], which is supposed to return the canonical version of that host name [For example, on some systems gethostbyname might return "foo" which would be mapped to "foo.bar.com" by gethostbyname]. Assuming this is successful, $j is set to the fully qualified name and $m is set to the domain part of the name (everything after the first dot). The $w macro is set to the first word (everything before the first dot) if you have a level 5 or higher configuration file; otherwise, it is set to the same value as $j. If the canonification is not successful, it is imperative that the config file set $j to the fully qualified domain name [Older versions of sendmail didn't pre-define $j at all, so up until 8.6, config files always had to define $j].

The first file (not necessarily the most important) I'll cover that is important for the proper startup of sendmail and definition of the macros described above is /etc/sysconfig/network. In this file there is a line that reads

HOSTNAME=something

Here's why that file is important: when your computer boots, the script /etc/rc.d/rc.sysinit is executed. It takes the variable HOSTNAME from /etc/sysconfig/network, and uses it to execute the command

hostname ${HOSTNAME}

The hostname command sets the host or domain name of the system, which is then used by many networking programs to identify the machine (I'm basically quoting the hostname man page here). It appears that sendmail's search for domain name information involves this name as well. The Linux Network Administrator's Guide, or NAG, suggests that the standard way to apply the hostname command is to use the unqualified host name with no domain name. That is, if you want to call your computer pinky, and it resides in the domain chia.earth.com, then your /etc/sysconfig/network should only contain the line

HOSTNAME=pinky

and not

HOSTNAME=pinky.chia.earth.com

The chia.earth.com part of your site's FQDN will be handled elsewhere. Now don't e-mail me and tell me this screws up sendmail, putting only an unqualified domain name in /etc/sysconfig/network. It doesn't, so long as you do everything else properly. I'll tell you the truth, though: I don't know of any specific reason why you ought to stick to just your site's unqualified domain name in this file; just goose-step along, you lemmings, and do it. To change /etc/sysconfig/network using netcfg, you should go to the "Names" section (the default when netcfg starts) and change the line labelled "Hostname:", to pinky. Don't worry about the "Domain:" line for the moment - changing it does not so far as I know affect sendmail at startup (it changes /etc/resolv.conf, which points to the name servers your site uses to connect IP addresses with domain names, and in some cases defines the return address that will appear in the "From:" line in the header of all the e-mail you send, but I'm getting ahead of myself).

Okay, assuming you'll follow my suggestion and just put your unqualified hostname in /etc/sysconfig/network, we can talk about the contents of two other important files: /etc/hosts and /etc/sendmail.cf. First, /etc/hosts:

The /etc/hosts file is described in the NAG, and I won't repeat any of that stuff, but know that this file is examined for information when sendmail tries to define the macros discussed earlier. If sendmail can use the contents of this file to get the hostname info it's looking for, it will start up just fine. Here's what to do:

For people with intermittent connections and/or dynamic IP addressing, your PC is probably not a fixture in your ISP's domain. You will use sendmail to do just that - send mail - and you'll want to use fetchmail or something similar to go to your ISP and get your mail (I know nothing about fetchmail, by the way). If you are such a person, I think the best way to go is as follows: First, make sure the name/s of the user/s who will be sending and receiving mail is/are the same on your PC as they are on your ISP's system. Now don't worry about making up some phony FQDN for your computer. Just get your /etc/hosts to look like this:

127.0.0.1     localhost

If you use netcfg for this task, go to the "Hosts" section, highlight the loopback entry by clicking over it, click on "Edit", enter localhost in the "Name:" field, make sure the "Nicknames:" field is empty, and you're done. DANGER: Don't put the unqualified domain name (e.g. pinky) in the "Nicknames:" field unless you plan to also put an FQDN in there. With an unqualified domain name pinky in /etc/sysconfig/network, a loopback name of localhost in /etc/hosts, and a loopback nickname of pinky in /etc/hosts, sendmail will hang at startup.

Now if you have a connection that is up 24/7/365 or very close, you can probably get an actual FQDN for your site and send and receive mail directly on your PC. People with dynamic IP addresses can even do this, thanks to Monolith, a cool group that provides free domain name service to all of us ISP-slaves who have an extra phone line. If you are in this type of situation, and your PC is in the domain chia.earth.com, here's what you should do with /etc/hosts: first, make sure that you give the loopback address the name localhost; second, include your fully-qualified domain name there as an alias/nickname. I also include the unqualified name (for the life I can't remember why), so that my /etc/hosts looks something like this:

127.0.0.1   localhost              pinky pinky.chia.earth.com

I've found that it doesn't really make any difference how these three names are arranged as far as sendmail is concerned, so I think these arrangements are also okay:

127.0.0.1   localhost              pinky.chia.earth.com pinky
127.0.0.1   pinky                  localhost pinky.chia.earth.com
127.0.0.1   pinky                  pinky.chia.earth.com localhost
127.0.0.1   pinky.chia.earth.com   pinky localhost
127.0.0.1   pinky.chia.earth.com   localhost pinky

Here's a rebuttal from the redhat-list archives:

This is a very bad solution - localhost should be associated with
127.0.0.1 and no other address.  The above will prevent certain
programs from working (such as talk).

A better way, if you have a dynamic IP, is to use the dummy interface
and assign it a non routed IP address (eg. 10.0.0.1) and route this in
the kernel.  For example, you could do:

ifconfig dummy 10.0.0.1
route add -host 10.0.0.1 dev dummy

Then add to /etc/hosts

10.0.0.1	myhost.mydomain.com	myhost

This will give you a valid host address (whether online or not).  This
method can also be used with dialup static IP accounts in order to get a
working address/domainname regardless of current connectivity.

> Markus

With all due respect to Markus (who seems to know what he's talking about - thanks to Markus for the info) I don't know if this is true. I have used the very bad solution for quite a while now with no problem, and somebody, at least one person and no more than two, rebutted this message, pretty much saying "nuh-uh, the first solution works just fine, and it doesn't break anything". However, Markus' method does sound like it may be more rigorously proper. I haven't tried it. I use the first method, and my system so far as I can tell ain't broke.

Next, I'll cover /etc/sendmail.cf. This file is the big, scary config file for sendmail, not to be edited by hand, some would say. It's built with the m4 preprocessor from a file you can see, assuming you have the sendmail-cf RPM package that corresponds to your sendmail RPM (you should). The m4 file is /usr/lib/sendmail-cf/cf/redhat.mc. Another file, /usr/lib/sendmail-cf/cf/redhat.cf, should be identical to the /etc/sendmail.cf you started with when you installed Red Hat Linux. Many people will not have to touch this file. However, the things I suggest here will not hurt, and they may solve problems for you.

If you fit the example above of somebody that just wants to send mail via their ISP, and have left nothing but the name localhost in the loopback name column of /etc/resolv.conf, then you still have to make sure sendmail is getting info on your ISP's domain, and to do that you will probably need to add something to /etc/sendmail.cf - otherwise the "From:" line of your e-mails is liable to be "bob@localhost" or something like that and nobody will know where to send replies to your messages. Find the part of /etc/sendmail.cf that looks like this:

# who I masquerade as (null for no masquerading) (see also $=M)

DM

and put the tail end of your e-mail address after the "DM". So if your e-mail address is bob@ispname.com, the "DM" line in /etc/sendmail.cf should look like this:

DMispname.com

For people who have on their systems several users with different e-mail domains (e.g. you are bob@ispname.com and your wife is linda@who.org), you should probably skip the masquerading part and just have each user set their return address using their mail user agent (or MUA; common examples are elm, pine, and exmh) of choice. In pine, for example, go to the setup ("Configure or update Pine"), choose "Config", and edit the "user-domain" entry.

This next part is for people who actually have an FQDN. I don't remember why I did it (maybe for cosmetic reasons), but I listed the domain part of my FQDN (the stuff after the first dot) as the first "search..." name in /etc/resolv.conf, and listed the actual domain that my school's name servers sit in after that. Say my FQDN is pinky.chia.earth.com but my ISP (and its name servers) are in ispname.com. In that case, my /etc/resolv.conf looks like this:

search chia.earth.com ispname.com
nameserver 123.456.789.0
nameserver 123.456.789.1

Do the same, unless it offends your sensibilities or doesn't work. In that case, leave the chia.earth.com part out of /etc/resolv.conf - things ought to work regardless, with your FQDN in /etc/hosts. If you are still having trouble with your domain, try explicitly telling sendmail what it is: find the line in /etc/sendmail.cf that reads

Cwlocalhost

and change it to your version of

Cwpinky.chia.earth.com

Following these instructions should get you pretty well taken care of w/r/t sendmail, if you fit into one of the two categories I've discussed. As a final note, I'll show you how to see what sendmail itself is doing when it runs. For simple info on your domain, do this at the shell prompt:

% /usr/sbin/sendmail -d0.1 -bt 

If your FQDN is pinky.chia.earth.com, the output should be

Version 8.8.5
 Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NETINET
                NETUNIX NEWDB QUEUE SCANF SMTP USERDB

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = pinky
  (canonical domain name) $j = pinky.chia.earth.com
         (subdomain name) $m = chia.earth.com
              (node name) $k = pinky
========================================================

If you are just using your ISP and don't have an FQDN, but you have named your 'puter pinky, you'll see this:

Version 8.8.5
 Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NETINET
                NETUNIX NEWDB QUEUE SCANF SMTP USERDB

============ SYSTEM IDENTITY (after readcf) ============
      (short domain name) $w = pinky
  (canonical domain name) $j = pinky
         (subdomain name) $m = (none)
              (node name) $k = pinky
========================================================

For even more info, change the debugging flag (the part after "-d") from "0.1" to "37.8". Hope this helps.

A few sendmail links