Differences

This shows you the differences between two versions of the page.

--- systemd-coredump [2018/11/16 11:33] – [Coredump configuration] rpjday
+++ systemd-coredump [2018/11/16 11:50] (current) – [Rules] rpjday
@@ Line 33: / Line 33: @@
 </code>
-===== core dump variables =====
+===== Configuring the core dump =====
+==== core dump variables ====
 <code>
@@ Line 52: / Line 54: @@
 </code>
+===== Piping to a program =====
+==== Rules ====
+  * The program must be specified using an absolute pathname (or a pathname relative to the root directory, /), and must immediately follow the '|' character.
+  * The command-line arguments can include any of the % specifiers listed above. For example, to pass the PID of the process that is being dumped, specify %p in an argument.
+  * The process created to run the program runs as user and group root.
+  * Running as root does not confer any exceptional security bypasses.   Namely, LSMs  (e.g.,  SELinux)  are  still  active  and may prevent the handler from accessing details about the crashed process via /proc/[pid].
+  * The program pathname is interpreted with respect to the initial mount namespace  as  it  is  always executed there.  It is not affected by the settings (e.g., root directory, mount namespace, current working  directory)  of the crashing process.
+  * The process runs in the initial namespaces (PID, mount, user, and so on) and not in the namespaces of the crashing process.  One can  utilize  specifiers such  as  %P  to  find  the  right /proc/[pid] directory and probe/enter the crashing process's namespaces if needed.
+  * The process starts with its current working directory as the root directory. If  desired,  it  is possible change to the working directory of the dumping process by employing the value provided by the %P specifier to change to the location of the dumping process via /proc/[pid]/cwd.
+  * Command-line  arguments can be supplied to the program (since Linux 2.6.24), delimited by white space (up to a total line length of 128 bytes).
+  * 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.