Sendmail won't start

[Matt Hearn]

Hi all! We had a network problem last night (we may have a bad card slot; we replaced the NIC yesterday and it's failed again, so we're running off of another NIC in the system at the moment), and it's resulted in a problem with sendmail; when I try to start it using the regular init.d script, it hangs. When I did a ps to see what it was doing, it appeared to be stuck on "newaliases." I thought that was weird, since we haven't made any aliases changes in a few weeks. It doesn't appear to be doing anything to aliases.db, so I'm not sure what the problem is.

I made a copy of the start script and commented out newaliases to just skip it since it's unchanged, but then it hangs on the sendmail startup.

I've tried moving aliases and aliases.db out of the way so newaliases can just say "nothing there" and quit, but it still hangs.

I'm hoping to get mail working without rebooting this production server for the 3rd time in 24 hours. Any ideas? Thanks!

[Mel Burslan]

Matt,

When you replaced the network interface, did you or someone physically unplug the network cable and put it in the new interface and re-assigned the IP address of the failed interface to the replacement one ?

Sendmail not starting and network interfaces getting replaced is pointing to a network problem. Even if you assigned the IP address of the failed interface to the replacement one, where the cable is going to on the switch end, if placed on a wrong VLAN, might be hampering the communications, holding sendmail, which by the way is very picky about network functionality, from starting up.

[Matt Hearn]

Here's what I did, step by step:

1) /sbin/init.d/net stop
2) Edit /etc/rc.config.d/netconf and simply set the reference for "lan0" to "lan1."
3) Switched the physical ethernet cable from lan0 to lan1.
4) /sbin/init.d/net start

Immediately I could ping the server and was able to ssh in. Nothing was changed on the switch side, so the VLANs and routing and everything else should be the same.

My guess is that SOMETHING (ARP tables, routes, shared memory, etc.) is being cached or held in place by the system; a reboot would undoubtedly clear it (we had the same problem yesterday and had to reboot the box to get it networked; it came up clean, sendmail worked fine). Problem is I can't reboot the box at this particular instant as everything's working but sendmail. (This is a backup server, and the production backup of BCVs is running.)

I may just have to wait until I can reboot, although we're probably looking at replacing a whole PCI card cage (this is an rp7420) because we've tried two NICs in the cell 0 core I/O slot and they're both doing the same thing.

[Mel Burslan]

If you are suspecting from an arp resolution issue, you can print the arp table to a file

arp -a > myfile # arp -an if you prefer IP addr. over hostnames

then find the mail relay servers and dns/domain controllers in this file. Remove them one by one using

arp -d hostname # or ip_address

if there are too many, script it out and give it a whirl. Nothing you can lose at this point by deleting some arp table entries I suppose. If and when they are needed, provided your networking is still good, they will be re-populated into the table.

[Steven E. Protter]

Shalom,

lanscan
# get the lan number of the new interface

All you should need to do is edit /etc/rc.config.d/netconf

If the old NIC was lan0 and the new one is lan1

Then the entries that were [0] in netconf will need to be 1.

DO NOT store a backup of netconf in /etc/rc.config.d that will cause them both to be read and neither to work.

For normal system function after changes reboot is best.

No sendmail configuration changes should be needed.

SEP