Question
uWSGI graceful reload and lazy‑apps interaction: worker recycling order and version consistency
Sky Atlas
0 reputation · 03 Dec 2022, 00:33 UTC
51.8K views1
Loading…
0 reputation · 03 Dec 2022, 00:33 UTC
Determine how uWSGI's graceful reload (SIGUSR1 or touch‑reload) coordinates with --lazy-apps when workers are recycled, specifically whether a deterministic shutdown order can be enforced to avoid version skew across workers.
--lazy-apps loads the application independently in each worker, so code changes between worker restarts can produce mixed versions.--chain-reload recycles workers sequentially, yet documentation does not guarantee that the new version is fully loaded before the next worker starts.--reload-mercy timeout may terminate workers mid‑request if set too low.Questions:
--hook-post-fork) are safe for signalling that a worker has finished loading the new code before it accepts traffic?--lazy-apps with --chain-reload without exposing clients to version skew?35775 reputation · 03 Dec 2022, 11:44 UTC
No, uWSGI does not provide a strict, guaranteed worker-by-worker shutdown order during a graceful reload, and there is no documented hook that blocks traffic acceptance until a lazy-loaded app is fully ready. The closest built-in ordering control is --chain-reload, which recycles workers one at a time instead of in parallel. With --lazy-apps each worker imports the WSGI app after fork, so the exact code snapshot a worker sees is the one present on disk at its own start time.
uwsgi--reload-mercy.--lazy-apps defers application import until after the worker process is forked. Each worker loads code independently.--chain-reload makes the master recycle workers sequentially rather than in parallel. This is the only built-in ordering control.--chain-reload workers are replaced in an unspecified order. With --chain-reload the master does not wait for the new worker to finish its lazy app import before starting the next replacement.--hook-post-fork runs after fork but before lazy app load completes in typical configurations, and hook failures are not propagated as a reload barrier to the master.--lazy-apps is combined with --chain-reload. Skew can occur if the application code on disk changes while the chain is progressing, because each worker loads whatever is present at its start time.chain-reload, lazy-apps, reload-mercy and touch-reload values.--reload-mercy high enough for your p99 request latency to avoid mid-request termination.To give a precise recommendation on readiness signalling, I need one missing detail: is your deployment atomic via symlink swap before reload, or is code overwritten in place during the reload window? That changes whether chain-reload alone can avoid skew.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 03 Dec 2022, 06:02 UTC
While --chain-reload is designed to recycle workers sequentially to maintain availability, it is important to note that it does not inherently solve version skew when paired with --lazy-apps. Because --lazy-apps defers application loading until after the fork, the master process cannot verify that the new code is fully initialized and ready to handle traffic before moving to the next worker in the chain.
For those attempting to use hooks for synchronization, --hook-post-fork executes before the application is loaded. To ensure a worker is actually ready, verification must happen within the application's own initialization logic or via a health check endpoint. If strict version consistency is required across all workers, the standard pattern is to avoid --lazy-apps and rely on the master process to load the app once, then fork workers with the pre-loaded memory image.