Now that I think about it, this laptop has an SSD and hangs while my desktop systems have rotating disks (several) and do not hang.

The root of the matter is that sendmail needs to generate some random numbers for something (probably security related). The way to make it more likely that random numbers generated by the kernel are truly random is to use things such as mouse movements, key strokes, and other difficult-to-predict sources of events. I guess disk head movement was a source of such events (but I don't know that for a fact and haven't looked that hard to find out). That information is stored in a so-called entropy pool (a pool of random, if you will).

If your pool is empty, the system will block on random number requests until you gain enough entropy to generate a new random number.

So the two fixes are to put sendmail in the background so the boot sequence doesn't block waiting for entropy or to add an additional source of entropy so that sendmail doesn't block at all.

2 members found this post helpful.

Thank you for replying.

Your speculative explanation provided some information to help me search. Apparently this entropy thing is heavily dependent upon ioctl and interrupts. That is, hardware. Perhaps then there is a connection to the problem when running with an SSD.

Regarding the alleged fixes, well, the thought that pops into my mind is WTF. Classic Picard face palm moment. That's me blabbering out loud and not against you.

You are not responsible, but this is nuts.

Anybody running postfix or exim on an SSD see this problem? Can sendmail be recompiled to avoid the problem?

Now here is an interesting twist.

When I boot into run level 1 and then run init 3, sendmail starts normally. No delays. I even added init 3 to .bashrc to avoid additional delays. I was logging in and launching init 3 in far less time than the observed 50 second delay when booting directly into run level 3.

Can anybody explain why this happens?

See this page on Postfix random number sources. Using /dev/urandom will not block so if you can configure to use /dev/urandom it should avoid the delay.

This is the sendmail config page for random number config.

Hope there is something helpful there.

If you are typing on the keyboard to input stuff (such as your login information), you are adding to the entropy pool.

On my laptop, moving the mouse during the hang also moves things along.

Apparently enough to resolve the sendmail problem. Would generating fake keyboard input help avoid the problem?

I built and installed haveged. That does work, but I don't know, this whole thing -- sucks.

Poking more around the web indicates people developing embedded systems face a similar challenge.

I only use sendmail locally for sending system email alerts to my server. No emails go out of the private network. Seems this entropy need is based on supporting TLS. Can sendmail be recompiled to avoid this need for entropy?

Hmmm ...

Interesting problem ( /dev/random at boot on systems with SSD Drives only ).

This paper Linux Random Number Generator – A New Approach is may be relevant.

-- kjh

2 members found this post helpful.

@kjhambrick for the win!

From the linked article....

I read the first few paragraphs and then my head started hurting. The introductory paragraphs were sufficient to at least learn that somebody is aware of the problem. The author confirms that embedded systems, headless servers, and SSDs are affected. The current method of building entropy seems heavily dependent upon moving parts -- input/output. Many modern systems have none of that.

Okay, so the root cause is a design that fails with 21st century hardware.

Still does not explain why sendmail is, um, er, crappily, designed. A lack of entropy should not delay starting the daemon. Sendmail should start promptly and if additional entropy is needed then sendmail should manage that on its own -- in the background -- until that entropy is sufficient.

I don't remember if the problem started when i migrated to SSD but i also have / on SSD.

Why do you think it is crap design ? As Richard said, sendmail just needs randomness for something. It doesn't do anything bad.

There are some HASURANDOM checks in the source code so i suppose it should use /dev/urandom (i think it uses openssl and not directly open the device) and not block but when i ran it through strace, i got /dev/random instead.

My bad. I suppose my irritiation with the problem shows. I meant crappy with respect to handling entropy pools and the startup delay, not with respect to handling mail. Even then, perhaps "crappy" is a poor choice of words.

I have been using sendmail for as long as I have been using Slackware, about 15 years. Has worked fine all of that time. I have not looked at the configs since my original configuration because sendmail just worked and behaved all of these years for my simple private network. Now there is breakage. Likely from the kernel since no Slacker saw the problem prior to the 4.4 kernels. Are people using other distros, SSDs, and sendmail seeing the same problem? I suspect the problem is there but few see the delay. The difference is most of the other distros now use systemd, which is designed to empahsize booting services in parallel. My guess is few people have noticed, if at all.

Yes, backgrounding rc.sendmail is one of the work-arounds offered in this thread, which accomplishes much the same as systemd.

P.S. No, no, no, I am not advocating systemd. Please do not go down that road. I am only speculating why others are not reporting the problem.

All --

At the bottom of the original link is a link to the source code which apparently includes patches to configure and link into kernels 4.8, 4.9 and 4.10:

Linux Random Number Generator

I run the Postfix SBo SlackBuild myself and I've not seen the delay on my Pure-D SSD Laptop.

Moreover, I've been crazy-busy at work with a dev project, otherwise, I might try the 4.9.x patch ...

Maybe an adventurous Kernel Compiler Person taker will step up to the plate and take a swing ?

HTH.

-- kjh

I also want to echo that in my experience too, this is likely an SSD vs non-SSD issue. My old server, non-SSD, still running, does not have this issue with 14.2. It's the new server, with an SSD, I put together that has this issue. I was trying to compare boot logs between the two a few months ago, and just noted there seemed to be entropy available earlier and faster, in some sense, the older machine was a bit faster! Who knew that the hardware lacking entropy to draw from causes a fast machine boot to grind to a halt?

I agree that having an SSD only system is likely contributing to the problem. However, I was running a headless SSD only system with 14.1 and never saw this problem. In fact no hardware was changed between my 14.1 and 14.2 install.

Previously in the thread Richard Cranium mentioned the problem appeared for him with the 4.4.7 kernel, which was introduced in 14.2 when still in the Current branch.