Sleeping spaces are not restarting

Hi guys, we have some problem with this, i cant start my space again:

☰ Gradio Sidebar Menu - a Hugging Face Space by elismasilva

2 Likes

So I did refactory build to work but i think we have some problem with cpu space when it enter in sleep mode, lets wait next turn.

1 Like

It wasn’t my Spaces, but I encountered a similar case a few days ago.

  1. Even after pausing Spaces or performing a normal rebuild, the previous runtime persisted as a ghost (accessible and functional via API)
  2. If a ghost exists, the build completes but the app won’t launch anew
  3. Only a factory rebuild could eliminate the ghost runtime
  4. After that, it started working fine

So as a “folk remedy”: If you’re stuck, try a factory rebuild → If that fails, try a rebuild with an empty commit → If that fails, change sdk in README.md and revert it to clear the cache

1 Like

This is a recurring error, and I think it deserves to be investigated and corrected, because all the CPU space, once it enters sleeping mode, is not returning to active status when the visitor requests that it be woken up, now this repo Gradio Video Slider - a Hugging Face Space by elismasilva @hysts

1 Like

Yeah. I don’t think it happened much before, too…

Link: Another ongoing infrastructure issue (unsure related or not):

1 Like

Hi @elismasilva
Thanks for flagging this. We can reproduce the 500 error when trying to wake the Space.
At the same time, looking at the account, it seems there are currently 19 cpu-basic Spaces running. Since we introduced a limit a few months ago on how many cpu-basic Spaces can run concurrently, I would have expected a quota-related message to appear once that limit was reached.
Are you seeing any quota limit message when you create a new cpu-basic Space? If not, there may be something unexpected going on here, and we can look into it further.

1 Like

The original issue in that thread was caused by a DDoS-related incident and has already been resolved. The behavior also looks different, so it does not seem related to this case.

1 Like

I see. Got it.

Hi, thanks for the reply. Actually, I haven’t received any quota-related notifications yet. only this error:

1 Like

Thanks for confirming. Looks like the underlying issue is still that the account is hitting the concurrent cpu-basic Space limit, but instead of showing the expected quota-related message, it is currently returning a generic 500 error. We’ll look into that on our side.

For now, free users can run up to 8 cpu-basic Spaces at the same time. If you pause some running Spaces so the total drops below that limit, the Space that is currently failing to start should be able to start again.

2 Likes

Also, upgrading to Pro could be another option, since Pro users can run up to 20 cpu-basic Spaces concurrently.

1 Like

I understand. Well, perhaps instead of displaying a quota message to the user (since it might be a visiting user and not the creator), it would be interesting to look at the CPU processes that are running and put the one that has been running the longest into ‘sleeping’ mode to make room for the one the user requested to restart. This way, in my case, where there might be several component demos, I can ensure that the user trying to view that demo at that moment doesn’t leave without being able to run the application.

1 Like