ToddAndMargo via users writes: Would you believe the proc manual page, which directs you to the core manual page? To indicate that the core file is an external program. The core dumps are already turned on, except that they are fed to abrt, which stashes them away. This will, instead, create a plain file called "core" in the executable's directory. Set it back to what it was. echo '|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e' >/proc/sys/kernel/core_pattern Now, if you really want a core file, you don't really have to do any of that. You can leave core_pattern at its default value, and just pull the core file down, upon demand. I have a small shell script in my $HOME/bin directory: $ cat ~/bin/core #!/bin/bash exec coredumpctl -o core dump And after something dumps core, I just execute "core", and the core file appears in my current directory.

man 5 core

On 8/12/19 2:46 PM, ToddAndMargo via users wrote: From the coredumpctl man page            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. -- If simple questions can be answered with a simple google query then why are there so many of them?

On 8/12/19 4:27 PM, ToddAndMargo via users wrote: 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. So, yes.  By default the core files are kept in /var/lib/systemd/coredump/ If files are "missing" nothing can be extracted. -- If simple questions can be answered with a simple google query then why are there so many of them?

On 8/13/19 5:23 AM, ToddAndMargo via users wrote: No, you use coredumpctl. -- If simple questions can be answered with a simple google query then why are there so many of them?

ToddAndMargo via users writes: Well, if the program exits with the exit code that indicates that it dumped core, you can have your script automatically run coredumpctl to extract the core out.

ToddAndMargo via users writes: Well, then change the script so that it doesn't. But, if you're saying that the program forks, and the original process exits, then that's going to be a little bit of a pickle. First of all, it is not necessary to grab the core file immediately after the program dumps core. The command I mentioned before can be run any time thereafter, all it effectively does is pull the most recent core dump. Otherwise, your only realistic option is your original plan: modify core_pattern.

Jeremy Nicoll - ml fedora writes: That's not a named file, but a device. And this uses the device to configure the kernel to create a plain file named "core" in the event that a process faults and wants to generate a core dump.

On 2019-08-12 20:53, Samuel Sieb wrote: Thank-you to both Sam and Samuel for explaining this. -- Jeremy Nicoll - my opinions are my own

On 8/11/19 5:25 PM, ToddAndMargo via users wrote: 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