On 8/11/19 5:25 PM, ToddAndMargo via users wrote:
Hi All,
I have no idea what this tells me
$ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
Does anyone know of a list somewhere?
And why does it send out a pipe symbol?
What does this do?
# echo core > /proc/sys/kernel/core_pattern
Will "core" turn on core dumps?
And if so, how do I turn it back off after testing it?
And will it wipe out "%P %u %g %s %t %c %h %e"?
I am confused, -T
Follow up:
Thank you to everyone and a special thanks to Ed, who got me on the right track.
-T
Here are my notes:
Fedora 30 and systemd core dumps:
References: https://sigquit.wordpress.com/2009/03/13/the-core-pattern/ https://www.freedesktop.org/software/systemd/man/coredumpctl.html man coredump.conf 5 man coredumpctl 5
Under Fedora 30 and systemd, core dumpts are no longer dumps to a core files. They are dumped to
/var/lib/systemd/coredump/
in a special format.
To retrieve core dumps, use "coredumpctl":
To list all core dumps: # coredumpctl
For example: # coredumpctl | grep CimTrakFooBar | tail -2 Fri 2019-07-26 08:21:14 PDT 32530 0 0 11 missing /opt/Cimcor/CimTrakFooBar/CimTrakFooBarServer/CimTrakFooBarServer.bin Wed 2019-08-21 17:34:29 PDT 20069 0 0 11 present /opt/Cimcor/CimTrakFooBar/CimTrakFooBarServer/CimTrakFooBarServer.bin
The PID is the number to the left of PDT
note: if "COREFILE" is listed as "Missing", you can not retrieve the core dump
COREFILE Information whether the coredump was stored, and whether it is still accessible: "none" means the core was not stored, "-" means that it was not available (for example because the process was not terminated by a signal), "present" means that the core file is accessible by the current user, "journal" means that the core was stored in the "journal", "truncated" is the same as one of the previous two, but the core was too large and was not stored in its entirety, "error" means that the core file cannot be accessed, most likely because of insufficient permissions, and "missing" means that the core was stored in a file, but this file has since been removed.
To see information on a core dump, first look up its PID with coredumpctl, then
# coredumpctl info PID
Extract the last core dump of /usr/bin/bar to a file named bar.coredump Note: use the executable's name from the "info" line: Executable: /opt/Cimcor/CimTrakFooBar/CimTrakFooBarServer/CimTrakFooBarServer.bin
# coredumpctl --output bar.coredump dump /usr/bin/bar # coredumpctl --output CimTrakFooBarServer.coredump dump /opt/Cimcor/CimTrakFooBar/CimTrakFooBarServer/CimTrakFooBarServer.bin
Core dumps are globally configured by /etc/systemd/coredump.conf
# Defaults can be restored by simply deleting this file. [Coredump] #Storage=external #Compress=yes #ProcessSizeMax=2G #ExternalSizeMax=2G #JournalSizeMax=767M #MaxUse= #KeepFree=
From the coredump.conf(5) man page
MaxUse=, KeepFree= Enforce limits on the disk space taken up by externally stored core dumps. MaxUse= makes sure that old core dumps are removed as soon as the total disk space taken up by core dumps grows beyond this limit (defaults to 10% of the total disk size). KeepFree= controls how much disk space to keep free at least (defaults to 15% of the total disk size). Note that the disk space used by core dumps might temporarily exceed these limits while core dumps are processed. Note that old core dumps are also removed based on time via systemd- tmpfiles(8). Set either value to 0 to turn off size-based clean-up.
To look at your possible core dump settings:
$ cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
%p: pid %: '%' is dropped %%: output one '%' %u: uid %g: gid %s: signal number %t: UNIX time of dump %h: hostname %e: executable filename %: both are dropped
An example of how to use the above:
# mkdir -p /tmp/cores # chmod a+rwx /tmp/cores # echo "/tmp/cores/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern
Testing: To trigger a core dump: $ kill -s SIGSEGV PID Subsitute your PID $ kill -s SIGSEGV $$ Will kill your current shell