1

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

Tallmad
  • 111
  • 1
  • 3

2 Answers2

1

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.

Ladadadada
  • 26,337
  • 7
  • 59
  • 90
  • 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 01 '12 at 09: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 01 '12 at 09:48
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.

roberto
  • 1,827
  • 12
  • 8