Bc_example_rstudio problem/question

Get Help
1

Hello,

One of my users has tried out our test 1.6 Open OnDemand setup, and is encountering an issue with the Rstudio setup we have, which uses singularity and a largely unmodified script.sh.erb from github.

The user has a .Renviron file in their home directory which has a single line:

R_LIBS_USER=/path/to/user/libdir/%v

When they start up an Rstudio session, the R_LIBS_USER variable does show as set when checking with Sys.getenv() (complete with proper version replacing the ‘%v’ variable), but does not show up when checking .libPaths(). It’s my understanding that the .libPaths() should include the R_LIBS_USER path at start time, but I’m not an R user, so I may be misunderstanding that.

Their current setup has apparently been working properly for them when running command line R on our cluster.

In digging in to try and find out what was happening, I see from the bc_example_rstudio script.sh.erb that the rsession.sh wrapper file should be written with the final line:

exec rsession --r-libs-user “${R_LIBS_USER}” “${@}”

In checking the rsession.sh files generated by my setup, the final line of the wrapper is:

exec rsession --r-libs-user “” “${@}”

So it looks like the ${R_LIBS_USER} variable isn’t being set by the time the wrapper is written. I haven’t been able to determine from the example files, however, at what point it would get that value from the user’s .Renviron file, if that’s what should be done.

It does look like singularity is properly mounting the external paths needed to read the home directory and the path specified in the .Renviron file. It seems like it should be a simple matter for the contents of the .Renviron file to be passed to the script, but I’m not certain if there might be something singularity or R-specific that’s causing an issue.

Thank you for any suggestions.

2

I don’t think we look to source that file at all. I’m guessing that the R binary does so when it boots. I’ll open a ticket so future versions look for and try to source that file.

However, I was able to simple add an export R_LIBS_USER=/path/to/user/libdir/%v to my ~/.bashrc file and that worked just fine. Note you’ll have to use the export keyword, otherwise it won’t work.

1 Like
3

Thanks for the heads up. I’ve created this pull request into our example, so you may be able to copy from that and just source if it exists in the script.sh.erb.

1 Like
4

Thank you Jeff,

I tried exporting R_LIBS_USER in my .bashrc file, and it did populate the field in the wrapper script, so rsession now starts with a populated “–r-libs-user” option.

Unfortunately while Rstudio does still display the value in Sys.getenv(), it’s still not added to .libPaths(). Running a shell from within the Rstudio session shows the environment variable set. I guess for my issue, at least, the “–r-libs-user” rsession option wasn’t the root cause.

5

It’s the %v that isn’t being parsed correctly I don’t know if that’s a mistake in your example or if it was real, but, I was able to replicate the issue by appending %v to a real file path.

I even tried to do a /path/doesnt/exist and that actually worked, I mean, it loaded it into libPaths. So it must just need to parse the directory correctly, not actually test whether it’s real or actually exists.

1 Like
6

Thank you again Jeff,

It turns out I made a mistake in copying the user’s environment, my test account couldn’t access the R_LIBS_USER directory, and I expect that was what was preventing Rstudio from adding it to the .libPaths. Changing the permissions fixed that.

I copied your changes into my local script.sh.erb, and removed the export R_LIBS_USER from my .bashrc, and that appears to have fixed everything. It does seem like R was excluding the R_LIBS_USER value because it couldn’t access the directory.

Thank you very much!

7

OK I’ve figured this out after brute forcing all the options. Sorry for going down the wrong path for so long. You’re right that it was likely a permission problem.

  1. You don’t need the update I’ve provided to source the .Renvion file. RStudio is able to source it. I’ve deleted the ticket and the PR to our example.
  2. The directory does have to exist and be readable to show up in libPaths
  3. %v does get populated correctly.

Here’s an example of a bad path showing up in the env variable, but not the libPaths
bad_path_not_in_libpaths

Here the %v works. It turned into the R version 3.4.
percent_v_works

1 Like
8

Thank you Jeff,

It looks like my customer’s issue is likely tied to the inaccessibility of their specific $R_LIBS_USER path within singularity on the running node.

We make use of automount, and have found in at least some instances that if an automountable path isn’t already mounted on the node prior to starting singularity that trying to access the path inside of the container can result in an error:

/bin/ls: cannot access '/automounted/path/': Too many levels of symbolic links

We haven’t found an elegant solution for this, but have generally done well by having jobs access needed mounts prior to running singularity., e.g.:

ls /automounted/path/ && singularity exec ....

My current thought is if I can use the OodFilesApp.candidate_favorite_paths array that’s populated in the /etc/ood/config/apps/dashboard/initializers/ood.rb file to add an “ls pathname > /dev/null” line to the script.sh for each path at the start, that it may be sufficient to ensure that all relevant mounts are accessible.

I’m thinking something along the lines of:

#!/usr/bin/env bash

<%=
OodFilesApp.candidate_favorite_paths.each { |item|
    puts "ls" item.to_s
}
%>

# Load the required environment
setup_env () {
....

The above doesn’t work, though it’s closer than I expected to get being entirely new to Ruby. It gives an output of :

[#<Pathname:/automounted/path>]

when inserted into my script.sh.erb. Hopefully some minor changes will do the trick, and I can try including it in the scripts for any services we start inside singularity.

Thank you.

9

That is because the erb tag <%= some_expression %> sets in the rendered file whatever the return value of some_expression is.

One approach:

<% OodFilesApp.candidate_favorite_paths.each do |item| %>
ls <%= item.to_s %>
<% end %>
1 Like