This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |
| systemd-coredump [2018/11/16 11:49] – [Piping to a program] rpjday | systemd-coredump [2018/11/16 11:50] (current) – [Rules] rpjday |
|---|
| * The RLIMIT_CORE limit is not enforced for core dumps that are piped to a program via this mechanism. | * The RLIMIT_CORE limit is not enforced for core dumps that are piped to a program via this mechanism. |
| |
| | ==== /proc/sys/kernel/core_pipe_limit ==== |
| | |
| | When collecting core dumps via a pipe to a user-space program, it can be useful for the collecting program to gather data about the crashing process from that process's /proc/[pid] directory. In order to do this safely, the kernel must wait for the program collecting the core dump to exit, so as not to remove the crashing process's /proc/[pid] files prematurely. This in turn creates the possibility that a misbehaving collecting program can block the reaping of a crashed process by simply never exiting. |
| | |
| | Since Linux 2.6.32, the /proc/sys/kernel/core_pipe_limit can be used to defend against this possibility. The value in this file defines how many concurrent crashing processes may be piped to user-space programs in parallel. If this value is exceeded, then those crashing processes above this value are noted in the kernel log and their core dumps are skipped. |
| | |
| | A value of 0 in this file is special. It indicates that unlimited processes may be captured in parallel, but that no waiting will take place (i.e., the collecting program is not guaranteed access to /proc/<crashing-PID>). The default value for this file is 0. |