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

[Joshua Judson Rosen]

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.

-- 
Connect with me on the GNU social network: <https://status.hackerposse.com/rozzin>
Not on the network? Ask me for an invitation to the nhcrossing.com social hub!