Since I'm interested in examining core dumps (in order to submit them to the ones developing the application that crashed) I prefer to keep core dumping enabled at all times on my systems.
Here is a brief hands-on to core dumps management.
To check whether core dump is enabled, do this:
ulimit -c
If the result is '0', the system isn't configured to dump cores. Other values specify how large the core file can get. If you need untruncated dumps, as I do, the best thing to do would be to run:
ulimit -c unlimited
However, this doesn't permanently solve the problem. It will only work under the current user and in the current terminal.
To have core dumping enabled at all times, for all users and on all ttys, you have to set this option in your /etc/security/limits.conf file. Add to the end of this file the following lines:
* - core unlimited
root - core unlimited
Now, the next thing to do is to establish a naming scheme for the cores and a location where you want to have them dumped. Suppose you want to have core dumps in /core; if so, create the directory and then change ownership accordingly (to give your normal, non-root user write permission in that directory):
# mkdir /core
# chown joe:joe /core
The only thing left to do now is to instruct your system to dump cores there and to name them according to your preferences. In order to do this, edit your /etc/sysctl.conf file and insert somewhere a line describing the "core pattern" that you want to use. The available format specifiers for core naming patterns are the following:
%% A single % character
%p PID of dumped process
%u real UID of dumped process
%g real GID of dumped process
%s number of signal causing dump
%t time of dump (seconds since 0:00h, 1 Jan 1970)
%h hostname (same as ’nodename’ returned by uname(2))
%e executable filename
Since I'm interested in my cores to contain information on the name and PID of the process which created them and on the specific signal which led to the core dump, the line that I'd insert in my /etc/sysctl.conf file would be:
kernel.core_pattern = /core/core.%e.%s.%p
To have these changes take effect, you'd have to log out and login again. This is because the file /etc/security/limits.conf has also been altered. If this wouldn't have been the case, in order to reload the new /etc/sysctl.conf file, you'd have only need to run:
sysctl -p
which assumes the new settings are to be reloaded from the default /etc/sysctl.conf. Otherwise,
sysctl -p /path/to/sysctl.conf
would have been needed.
But since you did change both /etc/sysctl.conf and /etc/security/limits.conf, you'll need to log out and login again in order for all changes to take effect.
0 comments:
Post a Comment