Revert a change in 2.5.4 by calling getrandom in the mode that blocks if the urandom pool is not yet considered initialized.

If getrandom and the urandom and sysctl fallbacks fail, kill the process instead of trying dubious userspace entropy collection.

If you don't like it, don't use it.

In any case, if you run a kernel lacking the fairly new getrandom syscall, make sure your boot scripts are seeding /dev/urandom before anything calls this code to avoid the chance of catastrophically low entropy.

To perhaps clarify: the first point applies if you have a newer kernel with the "getrandom" syscall; the intent is that a process should block if there isn't adequate entropy at early bootup, rather than ignoring the problem. Once the pool is first initialized there's no further blocking, as with /dev/urandom.

The second point applies to older kernels lacking getrandom.

diana_coman: jfw: fyi, I got around to build Gales and it seems to have built fine on a CentOS 6 with gcc 4.9.4; there was just a short wtf moment when the... tar cmd failed; it turns out that the --sort option is available only from tar V 1.28 while my local tar is ... 1.23; I didn't see any version spec in the prerequisites though probably my CentOS 6 is about as old everything as one gets nowadays
jfw: diana_coman: hey glad to hear it! And good to know about the tar version; the sort & other determinism tricks also don't work on Busybox tar as found on Gales itself.
diana_coman: jfw: yeah, I got why there was the --sort

diana_coman: fwiw, after reading your very useful BUILD doc a couple of times, I still packed the whole thing into a script mainly for speed but on reflection I think you got the right balance there - easy for one to make own script but not pre-packaged.

jfw: I had considered implementing the tar format to surmount the limitations of the various implementations, but it's not pretty - historically fixed field widths with various extensions to surmount them. Ended up writing a shell archive tool instead, seen for example in the 'skeleton' script and gports. Should now be usable in place of tar actually.
jfw: good to hear re balance of automation.

diana_coman: I haven't yet got around to try deploying it too but at least there's a lenovo x200 unearthed that awaits to play the guinea pig.
jfw: Looking forward to hearing how it goes.
diana_coman: it might still be a while really.
diana_coman: re tar, I don't really think it's worth /serious priority atm tbh
jfw: yeah, and there's worse non-determinisms upstream of it IIRC

For the record, I had absolutely no idea DJB made a daemon manager. I kinda like the ultra-terse-but-thorough style, TBH.

One quick question: is there any documentation for the service facility? So far I've been restarting daemons by manually killing the underlying process and having "supervise" automatically restart it. Is this standard procedure, or am I just blindly spinning around?