Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

error message:

uWSGI worker 5 screams: UAAAAAAH my master disconnected: i will kill myself !!!

I use uWSGI as server to hold my pyramid app on Ubuntu 12.04

share|improve this question
uWSGI is a little bit dramatic, no? – Ladadadada Nov 1 '12 at 6:55

There are tons of reasons for the master to die, normally master's death is governed by the user, but if, for some reason, it dies abruptuly, the workers have to follow him. As the worker (being a child) has no way to know what happened, you cannot expect more infos.

A common error is sending KILL to the master to reboot/destroy uWSGI, this will lead to worker being 'orphaned'. Generally master's death should be reported in logs (with a backtrace in case of memory corruption), maybe if you paste them we could find the cause.

share|improve this answer

A little bit of Googling led me to this changeset (only available now in Google's cache) in which uwsgi_receive_signal() and that error message was added to signal.c. The current version of the code is here.

If the read() call returns 0 (meaning 0 bytes were read), then something is wrong with the master and the worker should exit. If the return value is less than 0, this indicates an error and the worker should exit. If the return value was greater than 0, it's a normal situation and the signal should be handled.

It seems there's no way to tell the difference between a worker exiting normally and an error causing the worker to exit because the same message is logged in both cases, so there's no way to be certain of the answer to your question "How it happened."

And that, children, is why log messages are important.

As @roberto mentioned, there might be other messages in the log that may contain more useful information.

share|improve this answer
that function is used to manage uwsgi signals, that are 'developer-governed' actions (nothing to do with posix/unix signals). The '0' you are referring to is the return value of the read(), meaning the peer descriptor has been closed by the master (and it only happens on his death). As this is an extreme corner case (as when the stack is shutdown, workers are destroyed before the master) the best thing to do is auto-kill – roberto Nov 1 '12 at 9:04
Whoops, yes, the decision is based on whether the read() was successful or not rather than what value the read() got. Successfully reading 0 bytes in this case should probably be considered an error. I'll change my answer to be more correct. – Ladadadada Nov 1 '12 at 9:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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