r-lib
v0.9.0.9000 trying to install private git remote saturates CPU
Perhaps I'm just catching the repo at a bad time, but because of the severity here I wanted to file this just in case it's not already on your radar.
Since the last release, recovery from a subprocess failing (specifically due to HTTP error when trying to read file tree from git remote) seems to be broken and now continues to spawn new processes until R is unable to allocate new sub processes, leaving all attempts running at 100% cpu usage in the background.
This breaks the R session - at least anything that attempts to spawn a new process like installing a package (with or without pak).
rm ~/.git-credentials
echo 'url=https://acme.org' | git credential reject
R -e 'pak::cache_delete()'
v0.9.0
Expected, subprocess fails and terminates, showing HTTP error suggesting there's a credentials issue
pak::pak("git::https://acme.org/team/pkg.git")
Error:
! ! error in pak subprocess
Caused by error:
! Could not solve package dependencies:
*git::https://acme.org/team/pkg.git: ! pkgdepends resolution error for git::https://acme.org/team/pkg.git.
Caused by error:
! Failed to download DESCRIPTION from git repo at
<https://acme.org/team/pkg.git>.
Caused by error in `stop(http_error(resp))`:
! Unauthorized (HTTP 401).
Hide Traceback
▆
1. └─pak::pak("git::https://acme.org/team/pkg.git")
2. └─pak::pkg_install(pkg, ...)
3. └─pak:::remote(...)
4. └─err$throw(res$error)
v0.9.0.9000
pak::pak("git::https://acme.org/team/pkg.git")
Error in `remote()`:
! Subprocess is busy or cannot start
Hide Traceback
▆
1. └─pak::pak("git::https://acme.org/team/pkg.git")
2. └─pak::pkg_install(pkg, ...)
3. └─pak:::remote(...)
note that before throwing the error, pak spawns as many processes as it can and they linger at 100% CPU usage. they persist after the error is thrown, bogging down the rest of the R session
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
138221 dgkf 20 0 8531792 85952 15704 S 100.0 0.0 0:03.47 R
138430 dgkf 20 0 8531792 85532 15276 S 100.0 0.0 0:03.46 R
138290 dgkf 20 0 8531796 85752 15496 S 100.0 0.0 0:03.45 R
138504 dgkf 20 0 8531796 85860 15608 S 100.0 0.0 0:03.42 R
138361 dgkf 20 0 8531788 85884 15632 S 100.0 0.0 0:03.11 R
138576 dgkf 20 0 8978188 51932 14588 S 102.0 0.0 0:03.06 R
138144 dgkf 20 0 8531792 85656 15404 S 34.3 0.0 0:03.48 R
Continuing to investigate, it might be related to renv. Deleting {renv,renv.lock} restores the expected error message.
This is what I see with the latest commit (5dbf17cbc1a4):
❯ pak::pak("git::https://acme.org/team/pkg.git")
Error:
! error in pak subprocess
Caused by error:
! Could not solve package dependencies:
* git::https://acme.org/team/pkg.git: ! pkgdepends resolution error for git::https://acme.org/team/pkg.git.
Caused by error:
! Failed to download DESCRIPTION from git repo at
<https://acme.org/team/pkg.git>.
Caused by error in `(function (e) …`:
! Failed to connect to acme.org port 443 after 75004 ms: Couldn't connect to server
I see the same with 0.9.0. Which makes sense, because nothing has really changed wrt this recently.
I only see a single subprocess, going <20% while libcurl is trying to connect, and then back to zero.
What's your credential helper setup?
What's your credential helper setup?
I tried my best to clear it using the steps at the beginning of the issue. Is there something I can run to double check?
--
After some further investigation, I think what is happening is that the pak subprocess is running the project's .Rprofile and activating renv. I think the root of the problem is actually in renv.
I'm not sure why I was originally seeing different results, but I'm guessing I wasn't making a 1-to-1 comparison.
I think I was seeing differences between versions because some state was being retained from my other attempts. I don't think the issue is new in the latest version.
I've been able to avoid this situation by setting RENV_CONFIG_AUTOLOADER_ENABLED=false.
My hypothesis right now still that the sub-processes spawned by pak are loading the .Rprofile, which runs source("renv/activate.R") and I think renv sees that pak is installed then attempts to install dependencies using pak, entering us into a loop of recursively spawning sub-processes until it exhausts the process limit.
My use case is supporting a team that wants to use renv to lock their development environment, but also wants to test against latest versions of packages in CI. In CI we run R with --no-init-file to avoid activating renv, but it's still getting activated when installing deps with pak::local_install()
Sorry for the irreproducible goose chase. Let me know if there are other details that I can offer to help chase this one down.