Reticulate issues in RStudio Server

rstudioserver
reticulate

#1

I'm having an issue with reticulate that only manifests in RStudio Server (1.1.456) on CentOS 7.5, running R version 3.5.1. In the example below, there's a failure to load pandas 0.23, stemming from a failure to find the right version of GCC.

Oddly enough, since Anaconda 3 comes with the necessary binaries, this works fine when running this code through an interactive R session at the command prompt, as well as using a local install of RStudio, but is only problematic on RStudio Server.

PATH and LD_LIBRARY_PATH variables are configured the same in both cases (i.e. /etc/environment matches /usr/lib64/R/etc/Renviron.site). Given that I've had other similar issues with compiled applications inside RStudio Server (e.g. Axioma's Java API), there seems to be something special about the RStudio Server environment, but I'm completely baffled as to what that might be.

library(reticulate)
pd <- import('pandas')
Error in py_module_import(module, convert = convert) : 
  ImportError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /opt/anaconda3/lib/python3.6/site-packages/pandas/_libs/window.cpython-36m-x86_64-linux-gnu.so)

If we downgrade to pandas 0.22 this works, but we then have similar issues with other packages, so it's been a game of whack-a-mole. I was tempted to link the required CentOS system binaries to the versions in /anaconda/lib, but tinkering with core libraries tends to be a bit perilous.

Any help would be greatly appreciated!


#2

The problem here is that RStudio attempts to load and use system libraries, while Anaconda-installed software attempts to use their own bundled versions of system libraries. Conflicts between these versions lead to problems like the one you're seeing.

My understanding is that Anaconda also provides RStudio as part of Anaconda, and I believe that version should bind to and use the Anaconda libraries and so work as expected within the Anaconda ecosystem.


#3

Thank you Kevin! Oddly enough, when we run the same using a compiled version of RStudio (not 'Server', and not the Anaconda distribution) on the box it works fine, so it seems like this is particular to RStudio Server?

Is there any way to force RStudio Server to look for the Anaconda libraries? Those folders are at the start of the search paths, but that doesn't seem to have any effect:

> Sys.getenv('PATH')
[1] "/opt/anaconda3/bin:/opt/anaconda3/lib:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/lib:/usr/lib64:/usr/lib64/R:/usr/lib64/R/bin"

> Sys.getenv('LD_LIBRARY_PATH')
[1] "/opt/anaconda3/lib:/opt/shared/src/barra/BarraOptimizer8.7/lib/intel64"

I suspect I may just be missing something non-obvious but fundamental (and therefore critical) when setting these variables in /etc/environment and /usr/lib64/R/etc/Renviron.site. This post is starting to make me suspect user error (e.g. LD_LIBRARY_PATH cannot be set in Renviron.site)...


#4

Is this the open source version of RStudio Server, or the professional version? Sessions on the open source version are not launched through a shell, so environment variables in the normal places won't be read.

The sessions should be children of the rserver process though, and so I believe these should inherit environment variables set for the rserver process. Does making sure rserver runs with LD_LIBRARY_PATH set make a difference?


#5

Eureka! We are using the open source version. Thank you for not bludgeoning me with the user manual, which would have been totally justified in this case. Your comments and a bit more targeted Googling led me here, under 'External Libraries', which of course was the exact issue.

Setting LD_LIBRARY_PATHS via Renviron.site was misleading me into thinking that the variable was set, when in fact it wasn't (at least not for RStudio Server). Thanks again...