As per title, the `core` manpage states: There are various circumstances in which a core dump file is not produced: [...] * The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell's ulimit command (limit in csh(1)). However, this is not actually correct when core dumps are piped to a program, as the section below states ... * The RLIMIT_CORE limit is not enforced for core dumps that are piped to a program via this mechanism.
Hi Luca, Do you have any experiments demonstrating the actual behavior? Could you show them? And do you suggest any specific patch for that page? You may consider reading <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING> if you would like to send a patch for the page. Thanks! Alex
> Do you have any experiments demonstrating the actual behavior? Could you show > them? On a system with systemd (or where /proc/sys/kernel/core_pattern is configured to pipe to a program), run `ulimit -c 0`, then run a program that segfaults (writing `int main() { *(volatile int *)0; }` in a `segfault.c` file and running `gcc segfault.c; ./a.out` should be sufficient). This creates a core dump, despite RLIMIT_CORE being 0. > And do you suggest any specific patch for that page? Something like adding ", unless the system is configured to pipe core dumps to a program" in that bullet point should be sufficient.
I believe this has been fixed now.