sendmail spews out error messages at boot

This is a photo of my monitor with the error messages.

Bugbuddy does not need sendmail, but a sendmail binary. This binary is
shipped by all MTAs such as postfix, exim, courier etc... I'd suggest
you ditch sendmail in favour of postfix (the default Ubuntu MTA when an
MTA was installed).

The cause of bug relates to the starting of network interfaces during the /etc/rc0.d/ phase of startup, and the contents of these files are responsible:

/etc/network/if-down.d/sendmail

and

/etc/network/if-up.d/sendmail

These files re-configure sendmail on boot, supposedly only if there's been changes that require the sendmail config to change, but in reality cause the error that was reported.

It happens because these files get called when filesystem is read-only, so the newly generated sendmail config files cannot be saved.

My tempory solution has been to remove the 2 files refered to above, until someone more skilled than myself works out how to do what they were meant to do without errors.

Hope that helps other people with the same problem.

I can confirm that error messages about sendmail configuration appear with Dapper Beta and does not disappear even after "remove package and all configuration files". So I followed the above advice and removed the if-up and if-down sendmail files. which solved the problem.

Confirming this. The problem appears to be that the sendmail files in /etc/network aren't removed when you purge the program. I'm raising the severity because this has quite serious consequences, in that it interrupts booting for a considerable time, and breaks usplash.

On Fri, 2006-05-26 at 13:52 +0000, Matthew East wrote:
> The problem appears to be that the sendmail files in
> /etc/network aren't removed when you purge the program.

Actually, it looks like none of the configuration files are removed, by
the look of my /etc directory. I seems to me that they probably should
be:

matt@kalliope:/etc$ sudo find . -name "*sendmail*"
./alternatives/sendmail-mta
./alternatives/sendmail-mta.8.gz
./alternatives/sendmail-msp.8.gz
./alternatives/sendmail-msp
./alternatives/sendmail.8.gz
./alternatives/sendmail
./alternatives/lib.sendmail
./logrotate.d/sendmail
./cron.daily/sendmail
./init.d/sendmail
./rc0.d/K19sendmail
./rc1.d/K19sendmail
./rc2.d/S21sendmail
./rc3.d/S21sendmail
./rc4.d/S21sendmail
./rc5.d/S21sendmail
./rc6.d/K19sendmail
./dhcp3/dhclient-exit-hooks.d/sendmail
./logcheck/ignore.d.paranoid/sendmail
./logcheck/ignore.d.server/sendmail
./logcheck/ignore.d.workstation/sendmail
./logcheck/violations.ignore.d/sendmail
./mail/tls/sendmail-server.cfg
./mail/tls/sendmail-client.cfg
./mail/tls/sendmail-common.prm
./mail/tls/sendmail-common.key
./mail/tls/sendmail-server.csr
./mail/tls/sendmail-server.crt
./mail/tls/sendmail-client.csr
./mail/tls/sendmail-client.crt
./mail/sendmail.conf
./mail/sendmail.mc
./mail/sendmail.cf
./cron.d/sendmail
./ppp/ip-down.d/sendmail
./ppp/ip-up.d/sendmail
./resolvconf/update-libc.d/sendmail

Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

>Confirming this. The problem appears to be that the
>sendmail files in /etc/network aren't removed when you
>purge the program. I'm raising the severity because this
>has quite serious consequences, in that it interrupts
>booting for a considerable time, and breaks usplash.

The problem also occours whilst it's installed, regardless of whether or not the service starts up during boot or not.

I rooted out the files causing the problem, and hacked them out, because I needed to use sendmail, and I didn't want to stop using dapper on a regular basis and go back to breezy. I might fix it if I have the time, it'd be nice to get something put into Ubuntu :D

Sendmail is installed the first time running the interactive Bug Buddy application. This error causes the startup process to "freeze" for over a minute (but pressing Ctrl+C at the right time helps). Ultimately, it's a problem that can easily be produced by a new user.

Now I know about the workaround to install postfix, but a new user may not. Can anything be done about this to fix it for Dapper users?

There are two slightly separate problems here:

1) sendmail is split over several packages, and the dependencies are a mess. So:
# apt-get install sendmail
# apt-get remove sendmail
will leave you with sendmail-base and sendmail-bin still installed. This accounts for some of the files Matthew found in /etc

2) some files get put into /etc/, and aren't removed even after removing all of the sendmail packages

I'm not sure which problems are caused by which of these two; the first is perhaps easier to fix?

networkmanager problems for me started with sendmail. I tried removing sendmail using aptitude but the problems continued. Prior to removal KNetworkManager would be in a loop trying to a bring a device up.

There looks to have been quite a few "hook" scripts lying around after removal causing networkmanager issues when trying to complete a dhcp transaction

example log messages:

Sep 11 10:53:01 localhost avahi-daemon[4905]: New relevant interface eth0.IPv4 for mDNS.
Sep 11 10:53:01 localhost avahi-daemon[4905]: Registering new address record for 192.168.0.17 on eth0.IPv4.
Sep 11 10:53:01 localhost dhclient: bound to 192.168.0.17 -- renewal in 586988 seconds.
Sep 11 10:54:30 localhost NetworkManager: <information>^IOld device 'eth0' activating, won't change.

all fine to here, then this ad infinitum:

Sep 11 10:54:35 localhost NetworkManager: <information>^IDevice 'eth0' DHCP transaction took too long (>99s), stopping it.
Sep 11 10:54:36 localhost NetworkManager: <information>^IActivation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled...
Sep 11 10:54:36 localhost NetworkManager: <information>^IActivation (eth0) Stage 4 of 5 (IP Configure Timeout) started...
Sep 11 10:54:36 localhost NetworkManager: <information>^INo DHCP reply received. Automatically obtaining IP via Zeroconf.
Sep 11 10:54:36 localhost NetworkManager: <information>^IActivation (eth0) failure scheduled...
Sep 11 10:54:36 localhost NetworkManager: <information>^IActivation (eth0) Stage 4 of 5 (IP Configure Timeout) complete.
Sep 11 10:54:36 localhost NetworkManager: <information>^IActivation (eth0) failed.
Sep 11 10:54:36 localhost NetworkManager: <information>^IDeactivating device eth0.
Sep 11 10:54:37 localhost NetworkManager: <information>^ISWITCH: no current connection, found better connection 'eth0'.
Sep 11 10:54:37 localhost avahi-daemon[4905]: Withdrawing address record for 192.168.0.17 on eth0.
Sep 11 10:54:37 localhost avahi-daemon[4905]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.17.
Sep 11 10:54:37 localhost avahi-daemon[4905]: Interface eth0.IPv4 no longer relevant for mDNS.
Sep 11 10:54:37 localhost NetworkManager: <information>^IWill activate connection 'eth0'.
Sep 11 10:54:37 localhost NetworkManager: <information>^IDevice eth0 activation scheduled...

manually ifup/down ing the device works fine.

I manually removed the following hook scripts:
/etc/dhcp3/dhclient-exit-hooks.d
/etc/network/if-up.d/sendmail
/etc/network/if-down.d/sendmail

and everything back to normal. I think the sendmail package should do this automatically on removal ?

That script should be:

/etc/dhcp3/dhclient-exit-hooks.d/sendmail

Jan 25 13:20:38 amd sm-mta[16898]: NOQUEUE: SYSERR(root): hash map "access": unsafe map file /etc/mail/access.db: World writable directory
Jan 25 13:20:38 amd sm-mta[16898]: ruleset=check_relay, arg1=localhost, arg2=127.0.0.1, relay=localhost [127.0.0.1], reject=451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L1K2Ni014192: to=postmaster, delay=4+17:00:17, xdelay=00:00:00, mailer=relay, pri=30184811, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L1077H012772: to=postmaster, delay=4+17:20:13, xdelay=00:00:00, mailer=relay, pri=30274811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L1077I012772: to=postmaster, delay=4+17:20:13, xdelay=00:00:00, mailer=relay, pri=30274811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L0e223010610: to=postmaster, delay=4+17:40:19, xdelay=00:00:00, mailer=relay, pri=30363128, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L0e224010610: to=postmaster, delay=4+17:40:19, xdelay=00:00:00, mailer=relay, pri=30364811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L0e220010610: to=postmaster, delay=4+17:40:19, xdelay=00:00:00, mailer=relay, pri=30364811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L0e221010610: to=postmaster, delay=4+17:40:19, xdelay=00:00:00, mailer=relay, pri=30364811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L0e222010610: to=postmaster, delay=4+17:40:19, xdelay=00:00:00, mailer=relay, pri=30364811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:38 amd sm-msp-queue[16842]: m0L00233007884: to=postmaster, delay=4+18:20:16, xdelay=00:00:00, mailer=relay, pri=30544753, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:39 amd sm-msp-queue[16842]: m0L00234007884: to=postmaster, delay=4+18:20:17, xdelay=00:00:00, mailer=relay, pri=30544811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:39 amd sm-msp-queue[16842]: m0L00235007884: to=postmaster, delay=4+18:20:17, xdelay=00:00:00, mailer=relay, pri=30544811, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please try again later.
Jan 25 13:20:39 amd sm-msp-queue[16842]: m0KMK2EH003163: to=postmaster, delay=4+20:00:20, xdelay=00:00:00, mailer=relay, pri=30998271, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred: 451 4.3.0 Temporary system failure. Please tr...

Several of these errors look more like configuration errors than actual bugs.

The "** ** You should issue '/etc/init.d/sendmail reload ** **' message seen by Alexander van Loon is issued whenever you have changed a configuration file and you run sendmailconfig. It seems sendmail is trying to update it's database files before the file system is mounted read-write. The problem could be solved by running sendmailconfig once the system is up.

In some of the other comments it is clear that network-manager is being run on the system. In general, it is a bad idea to run network-manager on a system which has a fixed IP address. You don't need it, so get rid of it. Network-manager is good for a laptop that is roaming and need to use many different ways to access the network. My experience is that it interferes with many of the services that are often needed in a server setting.

I would also be wary of running the avahi daemon on a mail server.

Finally, darthanubis obviously has a mode issue with /etc/mail, the directory is world-writable and that problem could cascade into the other error messages.

Morten, why is this bug now marked Incomplete?

Setting status back to Confirmed - no further information was requested, and the original bug report is perfectly valid.

Confirming this bug on Ubuntu 8.10. Boot time is significantly increased by this package... what can I do to fix it?

Also confirming on Ubuntu 8.10 (x86_64).
I did a "sudo aptitude install sendmail" and have not touched any configuration. On bootup it hangs for about a minute on the "Starting Mail Transport Agent (MTA) sendmail" step.

alecwh: Workaround in comment 2:
https://bugs.launchpad.net/ubuntu/+source/sendmail/+bug/43752/comments/2

Confirming this is in Jaunty. amd64

Confirming on Ubuntu 8.10 (x86_64). Also the command line "mail" (to send an email) takes a long time to complete, though the mail gets delivered eventually.

Is there any workaround or configuration change found yet?

Confirmed on Jaunty i386..

The residual network startup script also seems to cause intermittent problems when bringing up multiple aliases of a physical network interface..

confirmed sendmail-base and sendmail-bin removed, not running network-manager (is a server).

for now: for i in `locate sendmail | grep -v dpkg`; do sudo mv -R $i /dev/null; done

network aliases not affected by sendmail startup script: this is more likely caused by https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/114457 or https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/123773.

Have install sendmail from apt, and not configured it.. Adds a minute to boot time on my 3 laptops and a desktop running jaunty. Affects newbies, who don't expect to have to configure sendmail just to have it book without this delay.