Tim Burke ae6300af86 wsgi: Reap stale workers (after a timeout) following a reload
Add a new tunable, `stale_worker_timeout`, defaulting to 86400 (i.e. 24
hours). Once this time elapses following a reload, the manager process
will issue SIGKILLs to any remaining stale workers.

This gives operators a way to configure a limit for how long old code
and configs may still be running in their cluster.

To enable this, the temporary reload child (which waits for the reload
to complete then closes the accept socket on all the old workers) has
grown the ability to send state to the re-exec'ed manager. Currently,
this is limited to just the set of pre-re-exec child PIDs and their
reload times, though it was designed to be reasonably extensible.

This allows the new manager to recognize stale workers as they exit
instead of logging

   Ignoring wait() result from unknown PID ...

With the improved knowledge of subprocesses, we can kick the log level
for the above message up from info to warning; we no longer expect it
to trigger in practice.

Drive-by: Add logging to ServersPerPortStrategy.register_worker_exit
that's comparable to what WorkersStrategy does.

Change-Id: I8227939d04fda8db66fb2f131f2c71ce8741c7d9
2025-01-16 13:44:21 +11:00
..
2025-01-13 13:36:41 -08:00
2025-01-13 13:36:41 -08:00
2025-01-13 13:36:41 -08:00
2010-07-12 17:03:45 -05:00
2025-01-13 13:36:41 -08:00
2025-01-13 13:36:41 -08:00
2024-02-07 15:48:39 -08:00
2025-01-13 13:36:41 -08:00
2018-03-13 12:06:07 +00:00
2025-01-13 13:36:41 -08:00
2025-01-13 13:36:41 -08:00
2022-02-10 11:17:06 -08:00
2025-01-13 13:36:41 -08:00
2025-01-13 13:36:41 -08:00