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
ToddAndMargo via users writes:
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?
Would you believe the proc manual page, which directs you to the core manual page?
And why does it send out a pipe symbol?
To indicate that the core file is an external program.
What does this do?
# echo core > /proc/sys/kernel/core_patternWill "core" turn on core dumps?
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.
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"?
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.
On 8/11/19 6:01 PM, Sam Varshavchik wrote:
ToddAndMargo via users writes:
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?
Would you believe the proc manual page, which directs you to the core manual page?
And why does it send out a pipe symbol?
To indicate that the core file is an external program.
What does this do?
# echo core > /proc/sys/kernel/core_pattern
Will "core" turn on core dumps?
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.
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"?
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.
Thank you!
man 5 core
On 12 Aug 2019, at 04:48, ToddAndMargo via users users@lists.fedoraproject.org wrote:
On 8/11/19 6:01 PM, Sam Varshavchik wrote: ToddAndMargo via users writes:
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?
Would you believe the proc manual page, which directs you to the core manual page?
And why does it send out a pipe symbol?
To indicate that the core file is an external program.
What does this do?
# echo core > /proc/sys/kernel/core_patternWill "core" turn on core dumps?
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.
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"?
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.
Thank you!
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 8/11/19 9:05 PM, Andy Paterson via users wrote:
man 5 core
# coredumpctl list | grep -i cimtrak
TIME PID UID GID SIG COREFILE EXE Fri 2019-07-26 08:21:14 PDT 32530 0 0 11 missing /opt/Cimcor/CimTrak/CimTrakServer/CimTrakServer.bin
The core file is listed as missing. Poop!
Am I misunderstanding something?
Also, how do I extract a core dump out of this?
On 8/12/19 2:46 PM, ToddAndMargo via users wrote:
On 8/11/19 9:05 PM, Andy Paterson via users wrote:
man 5 core
# coredumpctl list | grep -i cimtrak
TIME PID UID GID SIG COREFILE EXE Fri 2019-07-26 08:21:14 PDT 32530 0 0 11 missing /opt/Cimcor/CimTrak/CimTrakServer/CimTrakServer.bin
The core file is listed as missing. Poop!
Am I misunderstanding something?
Also, how do I extract a core dump out of this?
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.
On 8/12/19 4:27 PM, ToddAndMargo via users wrote:
On 8/11/19 11:56 PM, Ed Greshko wrote:
"missing" means that the core was stored in a file, but this file has since been removed.
Is there some age out timer involved.
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.
And if it is not missing, how do I extract it?
By default the core files are kept in /var/lib/systemd/coredump/
If files are "missing" nothing can be extracted.
On 8/13/19 5:23 AM, ToddAndMargo via users wrote:
On 8/12/19 2:27 AM, Ed Greshko wrote:
By default the core files are kept in/var/lib/systemd/coredump/
If files are "missing" nothing can be extracted.
If it is not missing, how do I extract it from coredump? "cp"?
No, you use coredumpctl.
On 8/11/19 6:01 PM, Sam Varshavchik wrote:
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.
I do not have access to the shell that the program is running out of. But I DO have access to the script that the program runs from. Any way to add something to the script? (Script exists after the program starts [systemctl].)
ToddAndMargo via users writes:
On 8/11/19 6:01 PM, Sam Varshavchik wrote:
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.
I do not have access to the shell that the program is running out of. But I DO have access to the script that the program runs from. Any way to add something to the script? (Script exists after the program starts [systemctl].)
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:
On 8/12/19 3:37 AM, Sam Varshavchik wrote:
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.
The stinking script exits after starting the program.
Rats!
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.
On 2019-08-12 02:01, Sam Varshavchik wrote:
ToddAndMargo via users writes:
What does this do?
# echo core > /proc/sys/kernel/core_pattern
This will, instead, create a plain file called "core" in the executable's directory.
Excuse my interruption, but why would that create a file named 'core'? Why doesn't it just place 'core' in the named file?
Jeremy Nicoll - ml fedora writes:
On 2019-08-12 02:01, Sam Varshavchik wrote:
ToddAndMargo via users writes:
What does this do?
# echo core > /proc/sys/kernel/core_patternThis will, instead, create a plain file called "core" in the executable's directory.
Excuse my interruption, but why would that create a file named 'core'? Why doesn't it just place 'core' in the named file?
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 8/12/19 3:18 AM, Jeremy Nicoll - ml fedora wrote:
On 2019-08-12 02:01, Sam Varshavchik wrote:
ToddAndMargo via users writes:
What does this do?
# echo core > /proc/sys/kernel/core_pattern
This will, instead, create a plain file called "core" in the executable's directory.
Excuse my interruption, but why would that create a file named 'core'? Why doesn't it just place 'core' in the named file?
That's not a real file. It's part of a virtual filesystem called "procfs" which gives a filesystem interface to the kernel internal settings. If you run "mount" you will see a lot of mountpoints that have types that aren't real filesystems. In fact, most of them are not. (I was surprised by that when I checked right now.) /proc and /sys are the top-level mountpoints for most of them. One thing that shows they are not real files is that everything shows a size of 0 and the modification date is now.
# cat /proc/sys/kernel/core_pattern |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h %e
but
# ls -l /proc/sys/kernel/core_pattern -rw-r--r--. 1 root root 0 Aug 12 12:51 /proc/sys/kernel/core_pattern
On 2019-08-12 20:53, Samuel Sieb wrote:
On 8/12/19 3:18 AM, Jeremy Nicoll - ml fedora wrote:
Excuse my interruption, but why would that create a file named 'core'? Why doesn't it just place 'core' in the named file?
That's not a real file...
Thank-you to both Sam and Samuel for explaining this.
On 8/12/19 8:25 AM, 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,
Have a look at https://sigquit.wordpress.com/2009/03/13/the-core-pattern/
Doing the procedures there will create a core file in the specified directory and bypass the "systemd" method implemented in fedora.
As for fedora. The pipe causes the core file to be used as input to systemd-coredump.
A "man systemd-coredump" would be a good place to start.
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
-
Andy Paterson -
Ed Greshko -
Jeremy Nicoll - ml fedora -
Sam Varshavchik -
Samuel Sieb -
ToddAndMargo