Why does Ruby init its random number generator up front? (was: Ruby slow to launch)

[Joshua Judson Rosen]

On 08/08/2017 03:33 PM, Tom Buskey wrote:
> On Tue, Aug 8, 2017 at 3:18 PM, Joshua Judson Rosen  > wrote:
> 
> On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote:
> > On 2017-08-08 14:43, Bill Freeman wrote:
> >> 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.
> 
> I assume you meant not dependent.

He probably did actually mean "dependent", but also meant "before"
as in "well in advance of" and not "at the moment when"--
i.e. "why ruby is designed to require a random number before anyone
has asked it to do anything dependent on such a random number",
i.e. "why ruby is designed to require a random number despite not yet
having been asked to do anything that actually needs it".

I can't really offer any insight into the Ruby devs, but I can offer
a story that illustrates why someone might choose `eager PRNG initialization'
(what Ruby is doing) over `lazy PRNG initialization' (what Python and Perl do).

Once upon a time, I inherited a playlist-generator written in Perl;
the way it operated, it wold fork off subprocesses and do things
with random numbers in the subprocesses to select the next song in the playlist.

Basically something like this:

while (1) {
if (fork == 0) {
print rand . "\n";
exit;
} else {
wait;
}

sleep 1;
}

This all worked perfectly fine until I added a call, somewhere in the program
before it got into that loop, to some subroutine that itself needed to
generate a random number for some reason. I don't specifically recall what that
subroutine was..., but the point here is actually that it may not
have even been evident to me as the caller that somewhere down
in the bowels of the new subroutine the PRNG was going to get called.

But it completely broke my playlist-generator, basically like this:

print "One random number: " . rand . "\n";
while (1) {
if (fork == 0) {
print rand . "\n";
exit;
} else {
wait;
}

sleep 1;
}

Perl uses lazy initialization of its PRNG: if you don't explicitly initialize 
it,
it auto-initializes at the point of first invocation.

And if the first invocation is after a fork, the child process
receives a copy of the uninitialized PRNG and initializes it itself
without affecting the still-uninitialized PRNG in the parent process.
And this situation can repeat just the same for each child process.

But if the first invocation is _before_ a fork, then the child process
receives a copy of the _initialized_ PRNG state, generates `the next number'
without affecting the pre-initialized PRNG state in the parent process.
And this situation can repeat just the same for each child process--
with each child process inheriting _the same pre-initialized PRNG state_.

So, the lazily-initialized PRNG basically provided a trap for
the programs's authors/maintainers to fall into: everything `worked just fine'
until a subtle/hidden change occurred to the program's overall
entropy-consumption patterns. It was... interesting,
figuring out how the playlist-generator started to just repeat
the same song over and over again.

Eager initialization of course wouldn't have prevented the
`cloned PRNG state' problem, but it would have made it immediately
visible up front instead of laying a trap that snared me years later.
(also: there are ways of triggering a re-init on fork as well,
 and it looks like Ruby even does that--with an accompanying
 comment of "We don't want reproduce CVE-2003-0900.").

As Bill said, "predictability is a bad thing" when it comes to
the specific outputs of a random number generator;
but predictability of whether/when your generator is going to
DTRT or fail entirely is quite a nice thing :)


-- 
Connect with me on the GNU social network: 

Not on the network? Ask me for an invitation to the nhcrossing.com social hub!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Dennis Straffin]

Oops, I didn't see Ken's reply where he already figure this out (spotty cell 
service).

Where I work we were having this issue when bringing up new VMs. While  
provisioning, it would seem to just hang for 10 or 15 minutes when installing 
packages. No cpu usage, no disk io, no network io.  And every time you'd ssh in 
to the VM to run top, it'd start going again. Very frustrating.  Simply 
installing haveged first fixed the issue.

-Dennis

On August 8, 2017 5:47:11 PM EDT, Dennis Straffin  wrote:
>VMs lack hardware devices to fill up the pool of random numbers.
>Installing the haveged daemon will do expansion on the random numbers
>to keep the pool full.
>
>-Dennis
>
>On August 8, 2017 3:30:46 PM EDT, Ken D'Ambrosio  wrote:
>>On 2017-08-08 15:18, Joshua Judson Rosen wrote:
>>
>>>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 ;)
>>
>>Yeah... getrandom() apparently pings /dev/urandom by default which, as
>
>>per the getrandom manpage, blocks until it has entropy.  Sounds like 
>>we've wound up at much the same place: I took some data off of 
>>/dev/random, stored it in a file, and am feeding that to /dev/urandom
>>at 
>>boot time (and re-seeding the file after five minutes' uptime).  Alas 
>>(because, you know, deadline), that doesn't seem to be working.  Which
>
>>is really, really annoying.  I'm *still* blocking for three-to-five on
>
>>getrandom().
>>
>>I guess it's time to cut my losses and start this in a different 
>>language.  I mean, most of the hard stuff was figuring out *how* to do
>
>>things, but I admit, my Perl and Python have grown rusty as I've
>>enjoyed 
>>my Ruby...
>>
>>-Ken
>>___
>>gnhlug-discuss mailing list
>>gnhlug-discuss@mail.gnhlug.org
>>http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>-- 
>Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Dennis Straffin]

VMs lack hardware devices to fill up the pool of random numbers. Installing the 
haveged daemon will do expansion on the random numbers to keep the pool full.

-Dennis

On August 8, 2017 3:30:46 PM EDT, Ken D'Ambrosio  wrote:
>On 2017-08-08 15:18, Joshua Judson Rosen wrote:
>
>>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 ;)
>
>Yeah... getrandom() apparently pings /dev/urandom by default which, as 
>per the getrandom manpage, blocks until it has entropy.  Sounds like 
>we've wound up at much the same place: I took some data off of 
>/dev/random, stored it in a file, and am feeding that to /dev/urandom
>at 
>boot time (and re-seeding the file after five minutes' uptime).  Alas 
>(because, you know, deadline), that doesn't seem to be working.  Which 
>is really, really annoying.  I'm *still* blocking for three-to-five on 
>getrandom().
>
>I guess it's time to cut my losses and start this in a different 
>language.  I mean, most of the hard stuff was figuring out *how* to do 
>things, but I admit, my Perl and Python have grown rusty as I've
>enjoyed 
>my Ruby...
>
>-Ken
>___
>gnhlug-discuss mailing list
>gnhlug-discuss@mail.gnhlug.org
>http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: 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.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Tom Buskey]

On Tue, Aug 8, 2017 at 3:18 PM, Joshua Judson Rosen 
wrote:

> On 08/08/2017 02:52 PM, Ken D'Ambrosio wrote:
> > On 2017-08-08 14:43, Bill Freeman wrote:
> >> 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.
>

I assume you meant not dependent.


> >
> > Email already sent. :-)
> >
> > C'est la vie.  I guess that's the way the Ruby crumbles...
>

That'd be a pretty bad design decision for some environments.


> 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
>
>

> 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.
>

The preseed might be a good 1st try at a fix that won't ruin the system RNG
and potentially compromising security.

This reminds me of the old days when Slackware was created because SLS
wouldn't fix permission issues correctly in the installer.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Ken D'Ambrosio]

On 2017-08-08 15:18, Joshua Judson Rosen wrote:

>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 ;)

Yeah... getrandom() apparently pings /dev/urandom by default which, as 
per the getrandom manpage, blocks until it has entropy.  Sounds like 
we've wound up at much the same place: I took some data off of 
/dev/random, stored it in a file, and am feeding that to /dev/urandom at 
boot time (and re-seeding the file after five minutes' uptime).  Alas 
(because, you know, deadline), that doesn't seem to be working.  Which 
is really, really annoying.  I'm *still* blocking for three-to-five on 
getrandom().

I guess it's time to cut my losses and start this in a different 
language.  I mean, most of the hard stuff was figuring out *how* to do 
things, but I admit, my Perl and Python have grown rusty as I've enjoyed 
my Ruby...

-Ken
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: L-o-n-g delay for rc.local in systemd on Ubuntu.

[Tom Buskey]

If you put it in systemd, it won't hold up login.  I can often ssh into
systems before the whole boot finishes.  I don't remember if the login: on
the console was affected.

I did Solaris 10 until about 5 years ago.  They replaced SysV init with SMF
which did dependency checking, etc.  Crucially, they kept support SysV init
scripts and slowly converted from them to the SMF XML formats.  Your 3rd
party init scripts kept working.  Since my S99 scripts never broke, I never
had to convert them.  It also took Sun until ~ 10.3 to get them working
well.

Systemd doesn't care about backward compatibility so stuff will break.
Worse, some stuff, like rc.local has partial support (that they don't care
about) and it will usually work like the docs say.

I've hit issues with service vs systemctl.  Ex: service mysql start vs
systemctl start mysql.  Service might *always* exit with status 3
regardless of success/failure.  My shell scripts that depended on 0/not 0
had to be changed.

That said, I've found systemd easier than SMF, especially if you abandon
the old ways.


On Tue, Aug 8, 2017 at 12:11 PM, Jerry Feldman  wrote:

> +1 for me also. When things like this change, we must also change with it.
>
> On 08/08/2017 12:08 PM, Dan Garthwaite wrote:
>
> +1 Tom.   Not to detract in any way from his answer - he is spot on and
> everyone should learn systemd if they are using systemd.
>
> If it isn't a daemon and just something that's gotta be done once after a
> power outage I've used CRON's @REBOOT.  Especially for non-root users.
>
>
> ___
> gnhlug-discuss mailing 
> listgnhlug-discuss@mail.gnhlug.orghttp://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>
> --
> Jerry Feldman  
> Boston Linux and Unix http://www.blu.org
> PGP key id:B7F14F2F
> PGP Key fingerprint: D937 A424 4836 E052 2E1B  8DC6 24D7 000F B7F1 4F2F
>
>
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: 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: 

Not on the network? Ask me for an invitation to the nhcrossing.com social hub!
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Ken D'Ambrosio]

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...

-Ken
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Bill Freeman]

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
developers.

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  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
> integer??
> * 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
> bad.
>
> 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.
>
> -Ken
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

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

[Ken D'Ambrosio]

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 
integer??
* 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 
bad.

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.

-Ken
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: L-o-n-g delay for rc.local in systemd on Ubuntu.

[Jerry Feldman]

+1 for me also. When things like this change, we must also change with it.

On 08/08/2017 12:08 PM, Dan Garthwaite wrote:
+1 Tom.   Not to detract in any way from his answer - he is spot on 
and everyone should learn systemd if they are using systemd.


If it isn't a daemon and just something that's gotta be done once 
after a power outage I've used CRON's @REBOOT. Especially for non-root 
users.



___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/



--
Jerry Feldman 
Boston Linux and Unix http://www.blu.org
PGP key id:B7F14F2F
PGP Key fingerprint: D937 A424 4836 E052 2E1B  8DC6 24D7 000F B7F1 4F2F

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: L-o-n-g delay for rc.local in systemd on Ubuntu.

[Dan Garthwaite]

+1 Tom.   Not to detract in any way from his answer - he is spot on and
everyone should learn systemd if they are using systemd.

If it isn't a daemon and just something that's gotta be done once after a
power outage I've used CRON's @REBOOT.  Especially for non-root users.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: L-o-n-g delay for rc.local in systemd on Ubuntu.

[Tom Buskey]

If your system is using systemd, don't use rc.local.  rc.local is not
deterministic in systemd.  I've had to move everything out of rc.local and
learn systemd to get reliable starting.

I created something like this (run_on_boot.service)

[Unit]
Description=Run at startup
After=network.target network-online.target sshd.service

[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=/usr/local/bin/run_on_boot

[Install]
WantedBy=multi-user.target


Copy run_on_boot.service to /etc/systemd/system
systemctl enable run_on_boot

The above will run the file in ExecStart after the targets, etc on next
boot.  Systemd will do a topological sort on the dependencies to start
things in the right order and run in parallel if it can.

We used to throw things into rc.local or create a script, tack S99 on the
name and put it in /etc/rc3.d. The systemd group would eliminate rc.local
if they could, so it's barely supported.  It gets started at some random
time, not after everything else.

On Tue, Aug 8, 2017 at 10:28 AM, Ken D'Ambrosio  wrote:

> Hey, all.  I've got some stuff in my rc.local, and it takes *forever* to
> execute -- three+ minutes.  (Note that the machine -- a virtual one --
> is up in something like 20 seconds.)  I *need* this stuff, which is
> lightweight in the extreme, to execute much more quickly than that.
> Anyone have any ideas on how to make that happen?
>
> Thanks,
>
> -Ken
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

L-o-n-g delay for rc.local in systemd on Ubuntu.

[Ken D'Ambrosio]

Hey, all.  I've got some stuff in my rc.local, and it takes *forever* to 
execute -- three+ minutes.  (Note that the machine -- a virtual one -- 
is up in something like 20 seconds.)  I *need* this stuff, which is 
lightweight in the extreme, to execute much more quickly than that.  
Anyone have any ideas on how to make that happen?

Thanks,

-Ken
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/