mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-16 14:39:31 -05:00
issue: Very long restart time after update to version 0.6.3x – takes several hours, no visible errors in logs #6880
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#6880
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Schwenn2002 on GitHub (Nov 10, 2025).
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.36
Ollama Version (if applicable)
No response
Operating System
Ubuntu 24.04
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
Open WebUI starts without significant delay after an update of the Docker container. The log should reveal which steps actually take so much time.
Actual Behavior
After an update, Open WebUI initially starts in an unhealthy state and is processing files (fetching files). It takes several hours (> 18 hours) before Open WebUI is available. There are no error messages in the log (debug log level). This behavior occurs with multiple versions. System utilization is consistently idle (htop, iftop).
Steps to Reproduce
docker-compose up -d open-webui
Logs & Screenshots
No Logs...
Additional Information
Description:
After updating Open WebUI to version 0.6.3x, the restart process takes an unusually long time — several hours in some cases. During startup, the logs show no explicit errors, but it appears to get stuck for a long period while fetching files.
Observed behavior:
htop,iftop) show no abnormal CPU, memory, or network activity.Relevant log excerpt:
Expected behavior:
Restart should complete within a reasonable time (a few minutes at most), as in previous versions.
Environment:
Additional context:
The issue started immediately after upgrading to version 0.6.3x. No configuration changes were made otherwise.
@nohalloween commented on GitHub (Nov 10, 2025):
similar problems:
I was handling with the openwebui-pipeline problem so I had to restart docker open-webui several times and after restarting for the last time, the log remains:
INFO [open_webui.env] Embedding model set: sentence-transformers/all-MiniLM-L6-v2
WARNI [langchain_community.utils.user_agent] USER_AGENT environment variable not set, consider setting it to identify your requests.
██████╗ ██████╗ ███████╗███╗ ██╗ ██╗ ██╗███████╗██████╗ ██╗ ██╗██╗
██╔═══██╗██╔══██╗██╔════╝████╗ ██║ ██║ ██║██╔════╝██╔══██╗██║ ██║██║
██║ ██║██████╔╝█████╗ ██╔██╗ ██║ ██║ █╗ ██║█████╗ ██████╔╝██║ ██║██║
██║ ██║██╔═══╝ ██╔══╝ ██║╚██╗██║ ██║███╗██║██╔══╝ ██╔══██╗██║ ██║██║
╚██████╔╝██║ ███████╗██║ ╚████║ ╚███╔███╔╝███████╗██████╔╝╚██████╔╝██║
╚═════╝ ╚═╝ ╚══════╝╚═╝ ╚═══╝ ╚══╝╚══╝ ╚══════╝╚═════╝ ╚═════╝ ╚═╝
v0.6.33 - building the best AI user interface.
https://github.com/open-webui/open-webui
nothing else appears
@Schwenn2002 commented on GitHub (Nov 10, 2025):
My complete log after 14 hours looks like this:
Last time I waited about 48 hours, then the service was suddenly available again.
@nohalloween commented on GitHub (Nov 10, 2025):
me too lol
@Classic298 commented on GitHub (Nov 10, 2025):
do you see anything if you set it to debug?
@Schwenn2002 commented on GitHub (Nov 10, 2025):
No, unfortunately no further information appears in the debug log level either.
@rgaricano commented on GitHub (Nov 10, 2025):
I think that it's because it's updating the embedd or rerank model/s, it can be slow for the traffic/system or by the hf auth (I had similar problems with the hugginface login client token,
huggingface-cli login),If you already have it downloaded and working you can bypass it setting env var
RAG_EMBEDDING_MODEL_AUTO_UPDATE="false"or env varOFFLINE_MODE="true"(There are other env var for that:
HF_HUB_OFFLINEbut not sure if it is used now, I can find it in the code)try it & if needed enable it in other moment.
@Schwenn2002 commented on GitHub (Nov 10, 2025):
Yes, those could be the files being downloaded (fetching files). But according to the log, that was already done successfully. What happens during the subsequent startup? It's been stuck there for 17 hours now, and there's no further log entry.
@rgaricano commented on GitHub (Nov 10, 2025):
If auto update enabled, on start the HuggingFace model loading functions checks if a newer version exists on their servers (comparing commit hashes in the model repository to determine if an update is needed, if the remote commit is newer than the local cache, it downloads the updated files)
For Ollama models is similar, but manual & it's compared the model digest (SHA256 hash), if the digests differ the updated layers are downloaded.
@Schwenn2002 commented on GitHub (Nov 10, 2025):
Issue: System freeze during CUDA initialization test with PyTorch
I tested whether CUDA was initialized correctly using the following command in the docker:
However, the system completely froze during the CUDA initialization step — there was no output, and I had to force a reboot.
After restarting Ubuntu, the issue was resolved and the same command executed successfully.
It seems that the system hang was related to CUDA initialization or driver state prior to reboot.