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.
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
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.
Is your script too complex to rewrite in bash? Not a general solution, but
as a workaround it has its appeal.
On Tue, Aug 8, 2017 at 2:24 PM, Ken D'Ambrosio <k...@jots.org> wrote:
> Well, I tried Tom's solution, and it made not a whit's worth of
> difference. Because, assuming my ignorance about systemd equated with
> slow boot time, I hadn't troubleshot further than that. Turns out that
> it's *Ruby's* fault. A command like this:
> ruby -e 'puts 1'
> is blocking for *THREE MINUTES OR MORE* on getrandom() for the first
> post-boot execution. (Subsequent ones run fine.) Which leads to all
> sorts of questions:
> * Why in the Hell do we care about getrandom() when we're printing an
> * Couldn't we just use /dev/urandom and be done with it?
> * So much etc.
> I love Ruby -- a lot -- but this is bash-my-head-against-the-monitor
> Any suggestions? Simply renaming /dev/random to something else and
> doing "ln -s /dev/urandom /dev/random" doesn't seem to be doing the job.
> gnhlug-discuss mailing list
gnhlug-discuss mailing list