4

Perhaps a more accurate title would be: "How to switch from in-place (EPEL) R to side-by-side (version-specific) R installation on Linux (Red Hat/CentOS)?

A (possibly typical) upgrading R on Linux story...

History:

At some point in the past, I updated the version of R on our RHEL/CentOS 7 server using the default version pulled down by the yum package manager at that time. For example, sudo yum install R to version 3.5.2 at some point in early 2019. By default, this installs R at /usr/lib64/R for all users and completely replaces the 3.4.x version that had previously been installed there. Shiny Server was already installed, configured to run as user shiny, and it picked up the new version of R without a hitch.

Situation:

A year later, it is now time to bite the bullet and update the version of R that is running on the Linux server. Running yum check-upgrade R I find that the version available is 3.6.0. I actually want to install 3.6.3 AND I don't want to break all of my apps that are running on 3.5.2, so I need to use a different method. Following the instructions found at https://docs.rstudio.com/resources/install-r/, I download the 3.6.3 .rpm file and install it. By default, this installs R at /opt/R/3.6.3/, leaving the 3.5.2 version as is. However, as soon as I complete the Create a symlink to R step, none of my shiny apps work:

sudo ln -s /opt/R/3.6.3/bin/R /usr/local/bin/R  
sudo ln -s /opt/R/3.6.3/bin/Rscript /usr/local/bin/Rscript  

This should not be surprising. My shiny apps all rely upon several R packages that have not yet been installed for this new version of R. I can quickly get my apps working again on the previous version (3.5.2) by removing these symlinks until after I've installed the necessary packages in the new version:

sudo rm /usr/local/bin/R  
sudo rm /usr/local/bin/Rscript 

Error messages in my shiny app log files (at /var/log/shiny-server/<app name>-<user>-<datetime>.log) confirm that the apps had failed to launch due to missing packages. To update the R packages in the shared library folder, I need to run the new version of R as sudo: sudo -i /opt/R/3.6.3/bin/R and install the necessary packages, e.g., install.packages(c("shiny","devtools","rmarkdown","shinydashboard","tidyverse")) in R.

Now that the R packages are installed, I can re-create the symlinks:

sudo ln -s /opt/R/3.6.3/bin/R /usr/local/bin/R  
sudo ln -s /opt/R/3.6.3/bin/Rscript /usr/local/bin/Rscript  

I verify that my apps are working with the new version of R.

Now I have some questions:

Question 1: After completing these steps, R --version still returns the old version (3.5.2). But when I logged back in the following day, it opens 3.6.3. Why? Do I need to run a terminal command to get R --version to return the new version immediately or is opening a new terminal window the only way to achieve this?

Question 2: Running sudo R --version always returns the old version (3.5.2). Running sudo which R returns /bin/R. Running more /bin/R reveals contents which state that it is "Shell wrapper for R executable." and has the "/usr/lib64/R" path hard-coded. I don't think I need this wrapper at this point. What is the recommended way to get these sudo commands to point to the new version?

I can make a backup copy of this file in my home directory (e.g., cp /bin/R ~/binR.backup) just in case, and then:

  • Delete /bin/R?
  • Replace /bin/R with a symlink to the new version (e.g., sudo ln -s /opt/R/3.6.3/bin/R /bin/R)?
  • Re-install the 'old' version into /opt/R/3.5.2/ using a .rpm the same way I installed 3.6.3, install packages there, and then remove the /usr/lib64/R version (e.g., sudo yum remove R)?

Links to similar questions that I looked at but didn't answer my questions:

  1. How to upgrade R in Linux
  2. Change path in Linux
  3. How can I load a specific version of R in Linux
Brian D
  • 2,570
  • 1
  • 24
  • 43

1 Answers1

4

Question 1: I'm not sure why, but having multiple versions of R on your PATH can lead to unexpected situations like this. /usr/local/bin is usually ahead of /usr/bin in the PATH, so I would've expected R 3.6.3 to be found. Perhaps it has to do with Question 2.

Question 2: Some distros (like CentOS/RHEL) don't put /usr/local/bin on the PATH by default when using sudo. See https://unix.stackexchange.com/questions/8646/why-are-path-variables-different-when-running-via-sudo-and-su for details. The answers there describe several ways to add /usr/local/bin to the PATH when using sudo -- for example, modifying secure_path in /etc/sudoers to include /usr/local/bin like:

Defaults    secure_path = /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

With R 3.6.3 ahead of the default system R in the PATH, you shouldn't have to delete /bin/R or /usr/bin/R. But eventually, I'd recommend installing multiple side-by-side versions of R the same way, using https://docs.rstudio.com/resources/install-r/, so it's easier to manage. The next time you install a new R version, you can just replace the symlinks in /usr/local/bin. The default system R (from EPEL) is meant to be the only R on a system, with in-place upgrades.

If you want to replace the default R 3.5.2 with a side-by-side R 3.5.2 (or 3.5.3), you could install R 3.5 from https://docs.rstudio.com/resources/install-r/, install all necessary packages, and have Shiny Server use the new R 3.5. Then uninstall the R from EPEL (R-core or R-core-devel) to fully switch over. From there, you could even create symlinks to R in /usr/bin instead of /usr/local/bin, and not worry about adding /usr/local/bin to the sudo PATH.

greg L
  • 4,034
  • 1
  • 19
  • 18
  • Aha! `/usr/local/bin` is ahead of `/usr/bin` for my user, but as sudo it is not there. That does seem to address Question 1 and I'll investigate this more. This is clarifying: "The default system R (from EPEL) is meant to be the only R on a system, with in-place upgrades." I hadn't been thinking of the two types of installs as 'side-by-side' and 'stand-alone'/'in-place' but that classification makes a lot of sense. Very helpful, thanks! – Brian D May 08 '20 at 15:00
  • 1
    Closing the loop: after removing the EPEL version (`sudo yum remove R`, and R-core, R-core-devel, R-devel, R-java, R-java-devel), `sudo which R` didn't find R anywhere anymore (since /usr/bin/R was removed). Creating a symlink `sudo ln -s /opt/R/3.6.3/bin/R /usr/bin/R` resolves this, as you say. – Brian D Feb 19 '21 at 23:39