The Space Does not Restart

Beginners
1

Somehow the log stuck at this place, the space itself is paused and I am getting 503 error when restarting the space. Could you help me out? Best regards

image
image872×416 17.6 KB

1 Like
2

Some errors that appear in Space may be due to regulatory violations, but in this Space’s case, it seems there’s a coding error. So you’ll need to fix that first to figure out the real cause.

Short, direct answer for your Space

  • You are not just “in the queue”.
  • The Space is paused, and when Hugging Face tries to start the container, the start-up fails, which is why you see Error 503.
  • In this specific Space (KaanGoker/GetSubtitlesApp), there is a concrete problem in your files: your supervisord.conf contains a big block of Markdown text that makes the supervisor config invalid, so the container crashes immediately.

So: the 503 is coming from a start-up/config error, not from simply being in a build queue.

1. What “Paused”, “Queue”, and 503 actually mean on Spaces

1.1 “Paused”

When you open your Space page, you see:

This Space has been paused.

That message is normal. Many Spaces show the same text when the app is not currently running (owner stopped it or HF auto-paused it for inactivity).

A paused Space is supposed to work like this:

  1. You (or a user) hits the Space.
  2. HF schedules the container to start.
  3. If the container starts successfully, the status becomes “Running” and you see your app.

If something goes wrong in step 2 or 3, HF shows a generic “503 – Something went wrong when restarting this Space” error. Multiple forum threads show exactly that wording when a Space cannot be restarted.

So:

  • “Paused” alone is harmless.
  • “Paused + 503 when you restart” means the restart failed (often because the container process crashed).

1.2 “Build queued” vs. runtime errors

In the build logs, Hugging Face prints a header like:

===== Build Queued at ... / Commit SHA: ... =====

That line is printed at the start of a build job, before Docker steps run. Seeing that line only tells you “a build was scheduled”, not whether your container later started successfully. HF forum posts show that sometimes builds really get stuck “queued” because of infra problems, but in those cases you usually see no 503 restart error, just endless “Building”.

Your situation is different:

  • The Space is already built (there is a Dockerfile, requirements.txt, etc. in main).
  • The UI says “Paused”.
  • When you try to wake it, you get a 503 restart error.

That pattern matches a container start-up failure, not “still waiting in a build queue”.

2. What is wrong in your Space

If we look at your repo:

  • Dockerfile is a normal Python 3.10 + FFmpeg + Supervisor setup, copies supervisord.conf, the app folder, streamlit_app.py, icons, and exposes ports 7860/8000.
  • streamlit_app.py is a Streamlit UI that talks to a FastAPI backend via BACKEND_URL, all fine.

The suspicious part is supervisord.conf:

[supervisord]
nodaemon=true

[program:backend]
command=uvicorn app.main:app --host 0.0.0.0 --port 8000
...

[program:frontend]
command=streamlit run streamlit_app.py --server.port 7860 --server.address 0.0.0.0
...

```      ← this line (start of a markdown code block)
---      ← markdown
### Adım 3: Kodu Hugging Face'e YĂŒkleyin (En Önemli Adım)
...      ← long markdown tutorial in Turkish
```bash   ← fenced code block
git add .
git commit -m "Deploy GetSubtitles v1.0"
git push
```      ← closing fence

supervisord.conf must be a valid Supervisor config file (INI-style sections + key=value pairs). It cannot contain Markdown fences (```), headings (###), lists, or shell snippets. That extra tutorial content is almost certainly causing supervisord to fail to parse the config and exit with an error.

What happens at runtime:

  1. HF runs the container with:

    /usr/bin/supervisord -c /etc/supervisor/conf.d/supervisord.conf

  2. supervisord reads the config.

  3. When it hits line ``` or --- or ###, parsing fails; supervisord exits immediately with an error.

  4. The container exits right away.

  5. HF tries to restart it, sees the process repeatedly failing, and shows 503 “Something went wrong when restarting this Space” – exactly what other users see when their main process crashes at startup.

So for this particular Space:

  • The 503 is almost certainly from the supervisor config being invalid.
  • This is a code/config issue inside your Space, not a simple “in queue / paused” situation.

3. How this compares to other 503 cases

There are several common causes of 503 on Spaces:

  1. Container crash / server process crash

    • In one “Space won’t start” discussion, an experienced user explains that when the main server process crashes (often due to RAM exhaustion), you get errors like this; the GUI can’t connect to the backend.
    • An invalid supervisord.conf like yours leads to the same symptom: the server never stays running.

  2. Moderation or prohibited libraries

    • Some Spaces get 503 because they use banned tools (e.g. crypto miners); HF staff explicitly mention blocking Spaces that include prohibited libraries.

  3. Infra / build-stack problems

    • Other threads show 503 or stuck “Building” when the HF registry or build system is having problems (401 from the registry, unexpected build errors, etc.), even for empty or unchanged spaces.

For your Space:

  • The code is a normal subtitle generator (FastAPI + Streamlit + Whisper), nothing obviously abusive.
  • There is a clear local config error (supervisord.conf with Markdown).

So you do not look like case (2), and you don’t need to assume an HF infra bug (3) until you fix (1).

4. What you should do next

4.1 Fix the supervisor config

Edit supervisord.conf so it only contains valid Supervisor settings, for example:

[supervisord]
nodaemon=true

[program:backend]
command=uvicorn app.main:app --host 0.0.0.0 --port 8000
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[program:frontend]
; HF expects the main app on port 7860
command=streamlit run streamlit_app.py --server.port 7860 --server.address 0.0.0.0
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

Remove everything after that (all the ``` fences, ---, headings, and git instructions). That sort of text should live in README.md, not in supervisord.conf.

Commit and push. HF will rebuild your Docker image. Once the build finishes, try restarting the Space again:

  • If the config was the only problem, the container should now start and the Space should leave the paused/503 state.
  • If you still see 503, check the runtime logs for new errors (e.g. out-of-memory, missing file, etc.), the same way people in the forums do when containers fail to start.

4.2 When to suspect queue/infra instead of code

After fixing obvious config errors like this, then consider HF-side issues if:

  • Builds suddenly start failing with registry or S3 errors (401 unauthorized, 404 NoSuchKey) like in the reported build-stack bugs.
  • A brand-new empty Space (no custom code) also returns 503, which HF staff have confirmed can be an infra issue.

In those situations, cloning into a new Space or contacting HF support is reasonable. But in your current state, the priority is to fix the invalid supervisor file first.

Final summary

  • “Paused” just means the Space is not running.
  • “Paused + 503 when restarting” means the container fails to start; you are not simply waiting in a queue.
  • In your GetSubtitlesApp Space, the supervisord.conf file includes non-config Markdown text, which is almost certainly making Supervisor crash, so the container exits immediately and HF shows 503.
  • Clean up supervisord.conf, push again, and then check whether the Space starts; only if problems persist after that should you start suspecting HF infra or moderation.
5

If you suspect an account issue, contact Hugging Face Support. website@huggingface.co

6

Hello,

I am experiencing a more nuanced issue with my Docker Space builds. They keep failing or pausing at different, random steps. Thanks for catching that error, I fixed that. Yet, I do not think this is an error in my code, but rather a platform or build system issue.

Here are the key problems I am facing:

1. Restarting a Space Never Works When a build pauses or the Space has an error (often a 503 error), I can never restart it. The “Restart” button does not work. I must delete the Space and create a new one for every single attempt.

2. It is Very Hard to Debug Because I have to create 5-10 new Spaces for each attempt, it is very difficult to find and fix errors. I had an error in my supervisord.conf file. It took me over 10 tries, (with exact same files) creating new Spaces each time, just to get one build to finish so I could see the container log and find the error. I fixed that error, and then I had to do the same thing for at least 10 tries to find and fix two more errors.

3. Builds are Failing at Random Points (I am Stuck) Now, I am using the exact same files for every build, but the build process pauses at a different, random step every time.

Here are my last three attempts from this morning:

  • Space “GetSubtitles”: Paused during the apt-get install (while installing adwaita-icon-theme).

  • Space “GetSubtitles2”: Paused much later in the apt-get install (at va-driver-all).

  • Space “GetSubtitles3”: Paused at the very beginning (“Build Queued”).

Compared to 14 hours ago, this time the same exact files cannot even pass through the “build” stage, so I can see if there is an issue inside the container page. All these last three attempts were done with advanced GPUs which were working 14 hours ago better. (Without random space pauses)

In total, I have tried 15-30 times. I was only able to see the real container log errors three times. I even had the application working one time and saw my UI, but after that Space went to sleep, it also failed to restart.

This seems like a platform issue, not a code issue. Could you please check if there is a problem with the build infrastructure or my account?

Thank you.

7

Deleted my posts by mistake. I am not sure about what is an account issue and what is not.

1 Like
8

Well, only Hugging Face can verify that