Hi there,

I'm facing a VERY strange issue since around Thu Mar 17 22:09:16 UTC 2016 -current changelog. Although I stated that it's sendmail related in the post title, I really don't know if sendmail is the culprit.

Look at this, from my /var/boot/log, a log file for the boot messages provided by bootp:

Now this:

These are the outputs of two different boots. Pay attention to the time difference between MTA and MSP start. In the first one, the difference is about a minute. In the second one, the difference is two seconds.

Where those two boots differ? The first one was unattended. The second one I hit a random key as soon as "Starting sendmail MTA" appeared.

So, in a normal situation, with no user interaction, an unattended boot take about a minute more just waiting for something. What it is waiting for is unclear to me.

I have already investigated the issue. /var/log/maillog looks healthy:

dmesg output doesn't reveal nothing special either.

All of this looks very weird to me. My modest machine used to boot up in less than 20 seconds before this issue hit the ground. Now it takes about 1'20", being that minute wait an annoying visitor.

Does anybody out there have seen or faced something similar lately?

Thanks in advance for any word.

I had put a sendmail command in one of the scripts to email me when my server booted up or shutdown. When I tried rebooting without a network connection, sendmail stalled because it could not connect. It would finally timeout and continue with the boot up.

Probably not much help. Just thought I would toss it out there.

I had a look in that too. No emails being sent upon boot up or shutdown. The issue happens regardless a network cable is attached or not.

I also took a look at /etc/hosts for the proper entries. localhost and its alias on the local network are there. /etc/mail/local-host-names matches the hostname for this particular machine.

Any word is a kind of help, @coldbeer. ;]

I ran into this some years past with a non-network connected machine. But you said it occurs connected or not.

I guess the obvious question is: Are you using Sendmail? I wasn't sure from your post.

If not:

To disable starting of sendmail when the system initializes, execute:

chmod -x /etc/rc.d/rc.sendmail

If nothing else disabling Sendmail will help narrow down the problem. Good luck!

Oh... and:

To start sendmail when the system initializes, execute:

chmod +x /etc/rc.d/rc.sendmail

Yes! I run some periodic verification tasks on this machine that reports results via email.

If something in your sendmail configuration is using /dev/random, the system may be attempting to gain entropy. Keystrokes gain entropy.

Just a guess.

1 members found this post helpful.

Hum! This worth a look! Thanks, @Richard Cranium!

By any chance, are you also getting a message in your maillog saying something like "My unqualified host name (localhost) unknown; sleeping for retry"?

I've had it happen a few times over the years and it's been related to an entry in /etc/hosts. Not sure if that's your issue, but it's probably worth checking.

Causes a delay during boot
Fixes the issue

Yeah i have the delay too since the upgrade. I haven't changed the sendmail config or hosts. At least in my case, the cause is what Richard Cranium said about entropy. Booting will stop until i press a key 4-5 times and the system gains enough entropy. The curious thing is why sendmail suddenly needs more entropy than before (or maybe the cause is another program from that upgrade that now "eats" entropy from the pool starving sendmail).

FWIW: my small, 32-bit system breezes right through the sendmail portion of bootup, without any need to touch the keyboard. Maybe sendmail is not the culprit?

No, @Diantre. /var/log/maillog is clean as water.

@speck, I have just this entry in /etc/hosts:

I couldn't add a mapping to the machine IP as it is DHCP defined. Anyway, I'm going to check if adding the LAN IP temporarily fix the issue. If it does, then I need to investigate a way to deal with that.

@imitheos: finally someone shares the issue with me (although I fell sorry for us.) The strange thing with this possibility is that sendmail package itself is not updated since Thu Oct 29 20:12:14 UTC 2015 (n/sendmail-8.15.2-i586-2.txz: Rebuilt.) It looks very unlikely that entropy required by it has been changed since. I don't know what other things could correlate with this to cause the issue we're facing.

@prtn: that's why I stated "I really don't know if sendmail is the culprit" in the OP.

Hmm. I have two machines running 64 -current. One of them used LUKS, so there are plenty of keystrokes to seed entropy. The other one doesn't and I didn't see any delay in starting sendmail.

I'm using the stock sendmail as it comes out of the box. Did you configure sendmail to do something useful? If so, could you share what you did?

denydias are you per chance running NTPd ? It hadn't occured to me till now to watch the entropy pool size and see what program drains it. I tried "poor man's debug" and put several "cat /proc/sys/kernel/random/entropy_avail" together with echoing at which part of the rc.S and rc.M we are. The result is the following:

After udev runs, the available entropy is 85 (bits ?). LVM and cryptsetup do not eat any entropy and it is still 85 until after mounting filesystems which raises it to 205. Seeding /dev/urandom with /etc/random-seed doesn't seem to give any entropy and i still get 205. When udev runs for the second time, the entropy is again raised to 275.

When NTPd runs it eats much entropy and it goes down to 134 and then acpid eats some more and drops it to 6 which makes sendmail hang. Disabling ntpd from running makes sendmail run instantly which is weird because neither ntpd had an upgrade when the problem started occuring.

2 members found this post helpful.

http://unix.stackexchange.com/questi...aining-entropy contains some interesting tidbits.