Switch back to using rserver

[yuvipanda]

• rsession doesn't work well with proxying shiny apps
• There seem to be problems with restarting too

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

See #56

[zeehio]

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]

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]

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

[wil]

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

[ryanlovett]

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]

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]

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]

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]

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]

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. :)