Unable to run multiple RStudio Server sessions at the same time
nickjer opened this issue · 5 comments
This could be due to both sessions sharing a common directory ~/.rstudio. Will need to look into modifying this through an rsession.conf with maybe the option session-default-working-dir and session-default-new-project-dir.
Found this useful article explaining the state saved/read for an R session:
https://support.rstudio.com/hc/en-us/articles/218730228-Resetting-a-user-s-state-on-RStudio-Server
Seems neither of those options affect the location of ~/.rstudio. It looks like it is hardcoded into the code.
Only trick I could come up with to fix this is:
Wrap around rsession (since env vars are wiped when this is launched) and set HOME=<where you want> before you call the real rsession:
#!/bin/bash
HOME=${HOME}/path/to/new/scratch/space exec rsession "$@"Then create an rsession.conf file that records where the real home directory is for the session:
session-default-working-dir=/users/appl/jnicklas
session-default-new-project-dir=/users/appl/jnicklas
Then launch the rserver with these new files:
rserver --www-port 5000 --rsession-config-file ${HOME}/path/to/rsession.conf --rsession-path ${HOME}/path/to/rsession_wrapper.shIt is ugly though.
I recommend we hold off on this until this becomes an actual issue to users.
Hi @nickjer , we are exploring ways to have a user run multiple R sessions in one RStudio Server Open-Source on one RHEL 7 machine. Is there a better way than the one you mentioned above?
Hi @nikolayvoronchikhin, unfortunately the problem (which I failed to originally capture) was running multiple RStudio Server (rserver) instances for a user concurrently. This allows us to better utilize HPC resources by giving each rserver and hence rsession process a full compute node with multiple cores for the user. But we had the issue that a user couldn't submit and have more than one rserver & rsession running concurrently without RStudio Server complaining due to the common workspace shared under the user's home directory. Fortunately, this can be resolved with a bind mount, in particular using containerization tools such as Singularity.
I have not explored the capability of running concurrent rsession's for the same user under a single rserver. I do not know enough about the internal workings of the reverse proxy code in rserver to say if this can be hacked together with the open source version. You could check out:
https://rpubs.com/jmcphers/rstudio-architecture
in particular the "RStudio Server Pro" section for an explanation of how it is done in the pro version. They describe using an rserver-launcher process. Maybe after reading the code there is a way to simulate that process?
One solution, which is how OnDemand works is to build a web portal in front (in essence a custom reverse proxy that behaves like rserver) that launches individual RStudio Server (rserver) processes on-demand for a logged in user. And then allows that user to connect to them or stop them when needed. This resolves the "multiple user rsessions's for a single rserver" issue for open source RStudio Server in a hacky way by just wrapping around rserver another reverse proxy that handles authentication and controlling individual rserver+rsession processes. This allows us to run multiple sessions and with different versions of R using the open source version.
If you want to go that route and keep it simple (not as big as OnDemand) you can explore using Node.js for the custom reverse proxy wrapper as that is what the RStudio Team is using for the Shiny Server: