我正在服务器上运行UWSGI并尝试在不使用dmesg的情况下跟踪工作进程何时获得OOM，因为这需要root权限。在这种环境中，如果一个孩子被SIGKILL杀死，那么OOM杀手可以做到这一点是安全的假设。
UWSGI在其日志中报告孩子被杀的信号。此问题（https://github.com/unbit/uwsgi/issues/25）显示了报告孩子已退出信号9的日志示例。
示例：
Oct 20 18:54:28 localhost app: DAMN ! worker 2 (pid: 16100) died, killed by signal 9 :( trying respawn ...
以下是UWSGI中负责此消息的代码行：
if (WIFSIGNALED(waitpid_status)) {
uwsgi_log("DAMN ! worker %d (pid: %d) died, killed by signal %d :( trying respawn ...\n", thewid, (int) diedpid, (int) WTERMSIG(waitpid_status));
}
https://github.com/unbit/uwsgi/blob/65a8d676f3e63a04b07fdcb4e1f92bb6502f024d/core/master.c#L1074
有没有办法计算使用SIGKILL查杀的子进程数，并将其表示为度量子系统内的指标？我也想知道超过harakiri超时的孩子是否被视为被信号杀死。
UWSGI似乎确实保持每个工人的信号数量，例如"signals": 0，但我不确定该字段的确切含义。
来自同一GitHub问题的示例：
"pid": 11360,
"requests": 294,
"respawn_count": 38,
"rss": 226373632,
"running_time": 628263,
"signals": 0,
"status": "cheap",
"tx": 5178,
"vsz": 380694528