I use the r-conda config a lot in my own binder repos, and when my rnaseq repo stop executing, I went and took a look at r-conda to see if a simpler config would work - and it appears not to any more.
The r-conda mybinder is at:
and (like my own repo) seems to get stuck like so:
Launch attempt 1 failed, retrying...
2023-10-04T13:19:23.756739Z [Normal] Successfully assigned gesis/jupyter-binder-2dexamples-2dr-2dconda-2dg3o52h09 to spko-css-app03
2023-10-04T13:19:24Z [Normal] Container image "jupyterhub/k8s-network-tools:3.1.0" already present on machine
2023-10-04T13:19:24Z [Normal] Created container block-cloud-metadata
2023-10-04T13:19:24Z [Normal] Started container block-cloud-metadata
2023-10-04T13:19:25Z [Normal] Pulling image "gesiscss/binder-r2d-g5b5b759-binder-2dexamples-2dr-2dconda-ee0ee6:a6b75fa39c46c4f6530867524665b4f0eb6abfc3"
Launch attempt 2 failed, retrying...
It actually launches fine. Traffic and remote sites can sometimes cause this to seem an issue. I just brought it up. I’ll send you a message here about a way that often seems to make it more reliable launching.
It looks like any newly built r-conda repo fails - I created a new empty one and even with the hack you gave me it runs into the same problem. So maybe something with the repo2docker build?
mybinder.org had a large reduction in capacity this year due to a reduction in donated cloud credits, so unfortunately a lot of repos will fail launch. We’re hopefully bringing some new servers online soon, though I don’t think it’ll be enough to fully make up for the list capacity.
understood - in this case, it seems like something else might be going on, but I definitely understand the reduced capacity problem too!
Can you try installing the dev version of repo2docker (from the
main branch) locally, and see if you have problems when runing locally? We’ve had to change how R is configured over the past year due to changes in how the binary packages are provided, so maybe some bugs have crept in.
I had a successful launch for binder-examples/r-conda at GESIS server (the one that you reported).
As mentioned, the mybinder.org federation is running under reduced capacity. The GESIS node can’t handle a large number of build of new containers simultaneusly due internet traffic.
I blocked half of my next week to see if I can improve the container built on the GESIS node.
No, the real issue is that launching from new builds using the r-conda repo as a template don’t work. That was the original issue that had @ctb investigating and then he just happened to then try the r-conda repo and hit the rough patch due to the MyBinder system being busy. So the title is a little misleading; it should better read ‘Repos based on the R-conda example aren’t working any more?’.
You can see that by going to this repo that is based on using the r-conda one as a template. If you go there and press the JupyterLab launch option at the top it will launch and then when you try to switch to RStudio from the launcher it will fail.
It will also fail if you try to adjust the URL by replacing
rstudio at the end.
Or it will also fail if you use the RStudio launch buttons that have
?urlpath=rstudio at the end.
One difference I see in the URL that pressing the tile from the launcher produces that doesn’t work is the addition of the port
:80 near the beginning, like so:
Whereas the link that launches from the old build at r-conda now where RStudio does work, makes something like this with no
It tried playing around with the URL to make it look like the other that works and that didn’t seem to help at first…
UPDATE - WORKAROUND TO GET INTO RSTUDIO INTERFACE in launches from newer builds:
I just stumbled on a workaround path to get RStudio to work in the session. It’s not easy but getting rid of the
:80 and passing the token in the authorization step is the trick. Do this:
- Use a launch ending in
?urlpath=rstudio as if you’d want to launch to RStudio directly.
- When the session comes up and says cannot provide a secure connection and invalid response, remove the
:80 from the URL. Hit return to pass that in to the current connection. It’ll refresh and the connection will add the
:80 back to URL automatically. However, that step will have passed the token in and authorized things in this session.
- Remove the
:80 from the URL, again. Replace
rstudio at the end of the URL with
lab and then hit return to enter that into the URL. Now it should go into the JupyterLab interface.
- Now you can go to the launcher pane in JupyterLab and press the
RStudio tile to go into RStudio interface.
Can you try forcibly upgrading jupyter-rsession-proxy in your environment to the latest version?
sounds like it might be relevant- repo2docker is using an older version without that PR.
That did sound promising. I upgraded to version 2.2.0 here, which should include that. Unfortunately, I still see the
:80 in the URL when I launch to RStudio directly using the launch link that has
?urlpath=rstudio at the end.