Issue #14837 has been updated by shevegen (Robert A. Heiler).


Makes sense.

As for Gem.user_dir:

> Arguably Rubygems could provide/recommend a way to get the user GEM
> dir without invoking Ruby.

The other way may be to have ruby directly support it sinec gems are
also bundled with ruby (and bundler already is or soon-to-be is).

For example perhaps RbConfig.user_dir or something similar. I am not
necessarily suggesting this (and in any way, it should then go into
a new issue request), but I think various assumptions by rubygems
were also made when rubygems was more of a separate add-on. 

----------------------------------------
Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCK
https://bugs.ruby-lang.org/issues/14837#change-72453

* Author: kevinoid (Kevin Locke)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: 2.5.1p57
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
Following the [instructions in the Rubygems FAQ](https://guides.rubygems.org/faqs/#user-install) I added the following to `~/.bashrc`:

~~~ sh
if which ruby >/dev/null && which gem >/dev/null; then
    PATH="$(ruby -e 'puts Gem.user_dir')/bin:$PATH"
fi
~~~

Unfortunately, this causes login to block for several seconds to minutes (depending on available entropy sources) because `ruby -e 'puts Gem.user_dir'` makes two `getrandom` syscalls without the `GRND_NONBLOCK` flag.  On [Linux v4.17-rc2 and later](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33), this causes ruby, and therefore the login process, to block until the RNG is fully initialized.

Arguably Rubygems could provide/recommend a way to get the user GEM dir without invoking Ruby.  That would solve the specific login problem reported above.  However, since even `ruby -v` makes two `getrandom` syscalls, I suspect this may cause difficult to diagnose hangs in startup or login scripts for many users and that it is a desirable use case to support, which is why I am reporting it here.

Some relevant history:  r51182 added `getrandom`, r51374 added `GRND_NONBLOCK` to address Bug #11395 (similar to this issue), r52808 removed `GRND_NONBLOCK` in some cases for `SecureRandom`.

Thanks for considering,
Kevin



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>