Help File Library: Core Dump Files and What To Do About Them

So you've installed the latest bleeding edge Linux distro, or have been trying out the latest beta release of KDE or Gnome. Now you're discovering a multimegabyte file, called "core", appearing in your home or root directory. Also known as a core dump file, they are usually produced when one uses software packages that are not quite out of the beta testing stage, e.g. bleeding edge desktop applications.

They are used by the developers for debugging an executable -- finding out information such as, exactly where a program crashed, the values of various variables, the calling contexts, stack frames, etc, in order to ascertain the problems and to effect corrective measures prior to recompilation. One need a debugger to do this ("gdb", "ddd" are good ones included in all major GNU/Linux/BSD distros).

But many new Linux users are not developers and can do without these files. You can safely delete the file without any ill effects. One way to ensure that all the core files have been eradicated is via a "find" command:

bash$ find $HOME -name core -exec rm -f {} \;

This assumes one has not created their own file named "core" containing something of value. If you're in the practice of doing this, please stop it now.

One can also prevent the core file from being created in the first place by using process limits. Linux can define certain restrictions to be placed on specific processes. Limits can apply to memory usage, file creation size, total number of open files, cpu time etc. You can view and change these limits yourself using a built-in Borne Again SHell (bash) command.

bash$ ulimit -a

This will display all limits currently in effect for the current instantiation of bash you're using. (Note that one can have multiple bash's running, each with different limits set.) To banish core dump files to /dev/null land:

bash$ ulimit -c 0

(Fans of tcsh, can use the equivalent command "limit coredumpsize 0".)

thus setting core dump size to zero, but this will only apply to processes launched from this particular instance of the bash shell. Applications launched from via another bash instance, or directly from the desktop menus or KDE/Gnome panel applets will be unaffected and can still leave core files if they crash. One needs to be able to restrict the core dump size *before* the desktop initialises.

This is why having a ~/.xsession file is very useful. For example, KDE users can create a simple ~/.xsession file with the following contents:

#!/bin/bash
ulimit -c 0
startkde

Note: Make sure this has the execute permissions set. If you use "gdm" or "kdm" select the "Default" desktop when logging in, otherwise your ~/.xsession will be ignored.

If all goes well the core dump limit will be imposed on the entire desktop process prior to startup. Only the .xsession owner will benefit from vanquished cores however. If the vast majority of graphical desktop users who log into your Linux box would also like to benefit a different strategy is called for. One can add the "ulimit -c 0" command near the top of the XSession file which can be found in /etc/X11. All users who login via the display manager will never see a core dump by default. Programmers and developers can undo this with "ulimit -c unlimited" to see core dumps in all their gory detail.

If you use "startx" you will have to add the "ulimit" command to the appropriate starting configuration file which differs from distro to distro. Just remember to set your limits prior to invoking "xinit" or "startx". A bash wrapper script might help here.

"man ulimit" for details on other process limits one can set. I find that misbehaving third party software can be brought into line via judicious use of "ulimit".

--
Adrian