uWSGI error: my master disconnected: i will kill myself. How it happened
Solution 1
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.
Solution 2
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.
Related videos on Youtube
Tallmad
Updated on September 18, 2022Comments
-
Tallmad over 1 year
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
-
Ladadadada over 11 yearsuWSGI is a little bit dramatic, no?
-
-
roberto over 11 yearsthat 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
-
Ladadadada over 11 yearsWhoops, yes, the decision is based on whether the
read()
was successful or not rather than what value theread()
got. Successfully reading 0 bytes in this case should probably be considered an error. I'll change my answer to be more correct.