Docker image built but failed to launch

Hi,

I’ve been using R package holepunch to make my R projects on GitHub repos binder-ready. It has worked without problems but failed for a recent project. The Docker image was built but failed to launch. Here’s the error that I repeatedly saw:

Successfully pushed turingmybinder/binder-prod-yanxianl-2dportraitr-b5bcf4:f25dade33d581786c9e2380ec6270d6a4510badcBuilt image, launching…
Launching server…
Launch attempt 1 failed, retrying…
Launch attempt 2 failed, retrying…
Launch attempt 3 failed, retrying…
Internal Server Error

I searched the forum for similar issues and modified my Dockerfile many times but couldn’t fix the problem. The binders (here and here) I built for my previous projects using the holepunch package can still be launched. I can’t figure out what the problem is.

Here’s the link to my GitHub repository that failed to launch.

Citing your old projects still launching isn’t equivalent. You’d have to trigger a rebuild to see if they successfully actually launch from a fresh build. I would suggest though not doing that until you actually know more so that they remain working though. Instead maybe you can find make a new one using the old one, or another fresh Holepunch-produced repo, and see if a fresh build launches?

Hi! Following your suggestion, I updated the README file in a previous project and triggered a new build. The build was successful and an RStudio instance was launched. I could run code online without problems.

Can you copy the recently-built working one then and try updating the rocker/binder version and MRAN snapshot dates to match what you are using on the one that fails to launch? I suspect those are causing the issue because there isn’t much more that is different.

Yes, it was the rocker/binder version and MCRAN snapshot date that caused the problem. Following your suggestion, the built image was launched. Thank you!

1 Like

Makes sense given my past experience/notes with Binder and using newer versions of R / snapshots / libraries. However, most of that I think was pertinent to the supported configuration file routes and not so much the Dockerfile route. (For example, see here and here and here and here and here and here.)

Glad you found your way forward.

1 Like