10

While the uwsgi documentation is perhaps fine for someone already familiar with server administration, it is definitely not so helpful for someone trying to learn it. I hope someone can help out with the questions below.

  1. I read, that it can close/reload processes gracefully. But what does that mean? And what is the alternative to closing gracefully?

  2. When is it that these processes can close gracefully/ugly? Is it if a process crash? Or if I chose to close uwsgi, eg by pressing ctrl+c? Or in some other case? Can I test out this gracefulness, eg provoke smth to crash / close, and then see the result with and without master?

  3. Does it do anything else than letting processes close gracefully?

  4. Since the enabling the master process is optional, there must be cases where it is not beneficial to use it. What are these cases?

10
+50

I agree with you that Uwsgi documents are quite good.

Now:

1)It means that uwsgi server will gracefully shut down/restart/reload its master process and its workers gracefully sending them a 'SIGHUP' signal, allowing the processes to respond to that signal: "flush buffers, close any established connections/sockets, e.t.c" (--reload) option

2) Alternative to 'gracefully' would be shutting down/reloading uwsgi application like you said 'dirty'. Meaning sending a master process and its workers 'SIGTERM' signal, hence brutally reload all the workers and the master process (--die-on-term). There is also '--stop' which is SIGINT that is actually would kill your entire uWsgi stack, also that is 'your keyboard interrupt Ctl+C behaviour"

3)You can play around with processes with those options and shut them down either gracefully or brutally, but behaviors are quite known, shutting down any application brutally/crashes doesn't resonate well, not allowing disk i/o operations finish, cache content stales, losing states e.t.c

4)Yes, sometimes you don't want uwsgi master process: From docs:

"As part of uWSGI's process management features, one can enable a master process to better manage worker processes. When this is enabled the WSGI script file or module will be preloaded into the parent master process. Worker processes will then be forked from this master process. This can cause problems if the WSGI script or module when loaded creates a background thread which is supposed to run in each worker process, as that background thread will be killed when the worker process are forked."

Hope this answers your question.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.