Ruby slow to launch (was L-o-n-g delay for rc.local in systemd on Ubuntu.)

[Ken D'Ambrosio]

Well, I don't know what was wrong with catting random data to 
/dev/random and /dev/urandom, but it didn't to diddly.  "apt install 
haveged", howver, and I'm now booting in ~20 seconds instead of 3 - 5 
minutes.  (It adds entropy -- or, if you prefer, "entropy" -- by seeing 
how long certain things take to execute, and then doing it again, and 
again, and looking for deltas.)

#winning

Thanks, all...

-Ken


On 2017-08-08 15:18, Joshua Judson Rosen wrote:
> On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote:
>> On 2017-08-08 14:43, Bill Freeman wrote:
>>> I don't know, but getrandom() may well be using /dev/urandom (or a
>>> related facility).  And that, in turn, might be waiting to "collect
>>> sufficient entropy".  So some network traffic, keystrokes, whatever,
>>> need to happen between boot time and the first random emission, or
>>> that first "random" number becomes predictable.  Since random numbers
>>> are often used cryptographically, predictability is a bad thing.
>> 
>> True, but there's debate about just *how* predictable, etc. Not a
>> subject for this particular thread, but I'd be perfectly happy with 
>> udev
>> almost-as-random.
>> 
>>> As to why ruby is designed to require a random number before being
>>> asked to do something dependent on such a random number is a question
>>> for the ruby developers.
>> 
>> Email already sent. :-)
>> 
>>> Re-linking /dev/urandom will probably break lots of things.  Maybe 
>>> run
>>> your script in a chroot jail that has a different /dev/urandom could
>>> work.
>> 
>> Alas, no -- I'm doing various admin chores, and a chroot won't be
>> helpful.
>> 
>>> Is your script too complex to rewrite in bash?  Not a general
>>> solution, but as a workaround it has its appeal.
>> 
>> *sigh* This is probably where I'm gonna wind up (or Perl, or Python).
>> Except I've now written a good handful of scripts that people are
>> waiting on, and it's gonna cause me physical pain to have to re-do 
>> them
>> at this point.
>> 
>> C'est la vie.  I guess that's the way the Ruby crumbles...
> 
> Instead of rewriting the whole thing, why not just seed the RNG 
> manually?
> 
> Slightly relevant-looking discussion BTW:
> 
>     https://bugs.ruby-lang.org/issues/9569#note-56
> 
> ... mainly in that it points to the updated random(4) Linux man page,
> which says:
> 
>        The  /dev/random  interface  is  considered  a  legacy  
> interface,  and
>        /dev/urandom is preferred and sufficient in all  use  cases,  
> with  the
>        exception  of  applications  which require randomness during 
> early boot
>        time; for  these  applications,  getrandom(2)  must  be  used  
> instead,
>        because it will block until the entropy pool is initialized.
> 
> So, there you go. "until the entropy pool is initialized" is apparently
> about 3 minutes in your case ;)
> 
> You should be able to explicitly seed Ruby's internal RNG,
> or explicitly seed the system RNG by writing bytes into
> /dev/random or /dev/urandom.
> 
> If you want `instant good entropy' at boot, you can even store
> some random data into a file at shutdown and then seed from that file
> at boot (be sure to invalidate that cache before seeding from it 
> though,
> to ensure that you don't use the same seed twice!). IIRC there are
> some preexisting packages for this, and some distributions even do it
> by default.
> 
> If you write a systemd service, it looks like you can depend on
> systemd-random-seed.service.