search

jupyterhub / jupyter-rsession-proxy

Jupyter extensions for running an RStudio rsession proxy
BSD 3-Clause "New" or "Revised" License
118 stars 87 forks source link

Switch back to using rserver #57

Closed yuvipanda closed 4 years ago

yuvipanda commented 5 years ago

This means we leave zombie rstudio processes behind - it daemonizes and we can't reap it :(

See https://github.com/jupyterhub/jupyter-rsession-proxy/issues/56

zeehio commented 5 years ago

Hi, I am having trouble to understand what is the latest version of jupyter-rsession-proxy, since this PR was apparently released to pypi but never merged into master. Is there a reason for this?

riazarbi commented 4 years ago

Hello.

Not to rush this but could we please get some clarity on this? I've successfully built a Docker image with RStudio Server 1.2, Jupyter 1.0.0 and jupyter-rsession-proxy==1.0.dev0 but if there's an alternative future path I'd like to try build it into my images now.

BertR commented 4 years ago

I just wanted to say that this PR has resolved the restarting issue we had with our Rstudio integration. Thanks!

wil commented 4 years ago

@zeehio agreed. @yuvipanda should this PR be merged into master?

ryanlovett commented 4 years ago

I've retested this on a local hub and found that rserver is not always successful. RStudio will timeout after 10s while attempting to connect to client_init and display a small error dialog window with the heading "RStudio Initialization Error" and the text "Unable to connect to service".

I debugged by launching a separate rserver process from the one that jupyter was starting for me. Initially I thought I found a missing required parameter to rserver to make it work, however I then couldn't reproduce the failure -- rserver started working of its own accord, both the debugging instance and the original process started by jupyter. The problem did return after restarting the user's jupyter server. I don't know if this is something particular to rserver or to the hub environment I'm testing in.

I am able to run rsession just fine, including a shiny app. Once RStudio is quit however, jupyter-rsession-proxy isn't able to start it again. (@yuvipanda's second point in the original report) If I can eliminate the problem above then I'm inclined to revert to rserver. It is possible to support both rserver and rsession via separate launchers, but I think that'd be confusing to users.

ryanlovett commented 4 years ago

I found that if I invoke rserver with --auth-minimum-user-id set to something lower than the user's uid, then the user is (logically) able to connect to RStudio. The default value for this parameter is "auto" which resolves to UID_MIN in /etc/login.defs if it exists, or 1000. Once rserver has been successfully invoked, if I then restart it with that parameter omitted, the user is able to connect to a new RStudio. Passing it in once frees up later rserver instances from abiding by that restriction.

If I restart the user's jupyter server, RStudio once again fails to start without the --auth-minimum-user-id parameter.

I can work around this by setting auth-minimum-user-id in rserver.conf.

scivm commented 4 years ago

I needed to increase timeout to 15 seconds or sometimes would get failures in azure cloud. Sometimes it just starts slow especially when you have just spawned a new pod.

./jupyter_rsession_proxy/init.py: 'timeout': 15,

I am using the rocker distro with tidyverse and then adding the needed jupyter stuff. I still have to see if rocker-binder is easier. rocker distro also starts up a little slower then just installing rstudio from binary. Maybe because it has more packages.

zeehio commented 4 years ago

If a user has multiple servers, each of them with a different RStudio session, I had to make sure the ~/.rstudio directory was unique for each of the servers with this: 

c.SystemUserSpawner.volumes = {
  '/home/{username}/.rstudio-jupyterhub/jupyter-{username}-{servername}': {'bind': '/home/{username}/.rstudio', 'mode': 'rw'}
}

Not sure if related to some of the errors someone may be getting

riazarbi commented 4 years ago

To add to this conversation, we've been using the pip version 1.0b6, which corresponds to this merge candidate, for the last 12 months with few issues. We did have a lot of trouble getting the Dockerfile just right.

Also, we run on Kubernetes so we don't really care about zombie processes - these containers are culled regularly.

In the interests of perhaps eliminating the possibility of confounding environmental issues, here's a link to my Dockerfile so you can see what the environment looks like.

https://github.com/riazarbi/datasci-gui-minimal/blob/master/Dockerfile

Some things to note -

  1. This dockerfile follows the jupyter docker stacks configuration quite closely. One needs to fix permissions to in the Docker build process to avoid permissions issues. I think this is a jupyterhub / jovyan problem not an rsession problem.
  2. rsession proxy will not work unless jupyter-server-proxy is also installed.

Hopefully this helps.

ryanlovett commented 4 years ago

I've closed this in favor of #84.

Rather than carry our own Dockerfile as an example, I've linked to rocker's in the README.md. I'm happy for someone else to be thinking about all of those environment issues. :)