Monthly Archives: March 2009

The Core Pattern (core_pattern), or how to specify filename and path for core dumps

1. Introduction to Core Dumps

In most GNU/Linux systems (all of those I personally have used, at least), core dump files generated after an uncaught signal in a process (as a SIGSEGV or SIGQUIT), are generated in the base directory where the program was executed, and named as “core” or “core.PID”.

For example:

$> cd /home/user
$> ulimit -c unlimited
$> kill -s SIGSEGV $$

This will trigger a segmentation fault in your current shell (you probably guessed it after seeing that the shell session where you executed it was closed), and generate a core file in:

Now… is it possible to change where that file is generated by default instead of the current directory? And is it possible to change the name of that generated file? The answer is YES! to both. Let’s see how we can get this.

2. The Core Pattern in Kernel

Since some years ago, the kernel configuration includes a file named “core_pattern”:

In my system, that file contains just this single word:

As expected, this pattern shows how the core file will be generated. Two things can be understood from the previous line: The filename of the core dump file generated will be “core”; and second, the current directory will be used to store it (as the path specified is completely relative to the current directory).

Now, if we change the contents of that file… (as root, of course)

$> mkdir -p /tmp/cores
$> chmod a+rwx /tmp/cores
$> echo "/tmp/cores/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern

And we run the same as before:

$> cd /home/user
$> ulimit -c unlimited
$> $> kill -s SIGSEGV $$

We get… voilá!

Not only the program name (“bash“) or the PID (“8539“), but also the hostname (“drehbahn-mbp“) and the unix time (“1236975953“) are appended in the name of the core file!! And of course, it is stored in the absolute path we specified (“/tmp/cores/“).

You can use the following pattern elements in the core_pattern file:

%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

Isn’t is great?! Imagine that you have a cluster of machines and you want to use a NFS directory to store all core files from all the nodes. You will be able to detect which node generated the core file (with the hostname), which program generated it (with the program name), and also when did it happen (with the unix time).

3. Configure it forever

The changes done before are only applicable until the next reboot. In order to make the change in all future reboots, you will need to add the following in “/etc/sysctl.conf“:

# Own core file pattern...

sysctl.conf is the file controlling every configuration under /proc/sys


Fedora 10 in Asus Mini Nova Lite PX24 (2): Wireless Networking

My friend Tomasz gave me yesterday the configuration to enable Wireless Networking at system-level (skipping NetworkManager) for Ubuntu. It’s just modifying /etc/network/interfaces to setup the Wireless device directly there:

auto lo
iface lo inet loopback
iface wlan0 inet dhcp
wireless-key s:your_f****_password_here
wireless-essid your_f****_essid_here

I wanted the same in my home Fedora 10 server, but as you already may know, Fedora 10 is based on Red Hat, so forget about the debian-like network configuration, and welcome to the system-config-* scripts!

You can edit your system-level network configuration, executing, as root:

$> system-config-network

(or clicking on System->Administration->Network)

In the Wireless Settings tab you should select “Managed” mode, and I also specified the correct SSID of my home wireless network. Be really careful if adding the WEP key in HEX, as you must prepend “0x” to the whole key or it won’t work.

I thought that this would be enough, but nope. NetworkManager is launched by default at system startup, not the /etc/init.d/network script, which is disabled by default. You just need to disable NetworkManager, and enable the standard “network” script in order to have the system-level wireless configuration, executing, as root:

$> service NetworkManager stop
$> chkconfig --level 35 NetworkManager off
$> service network start
$> chkconfig --level 35 network on

I really like chkconfig, but not sure if the “service” command is a needed replacement of executing the script from /etc/init.d directly.

Fedora 10 in Asus Mini Nova Lite PX24 (1)

I recently bought a small Asus Mini Nova Lite PX24 and of course, installed GNU/Linux on it. I chose Fedora 10 because at that time, it was the only distro I tested with the required driver for the Wireless interface:
Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter

Other distros I have tried in the Asus PX24 are:
* Ubuntu 8.04 Hardy Heron [Doesn’t work]
* OpenSUSE-11.1-GNOME [Doesn’t work]
* Debian 5.0 Lenny [Doesn’t work]
* Ubuntu 9.04 Jaunty Jackalope Alpha-5 [Works]

I was a Kubuntu fan until release 8.10, which completely destroyed the usability and stability of the distribution when shipping a non-stable version of KDE4. Switched then back to Gnome in Ubuntu 8.10, far more stable than the KDE counterpart. So now that I know that next stable version of Ubuntu also makes the Wireless networking work out-of-the-box, I thought of changing the PX24 back to Ubuntu.

But I won’t… I want to try yum, RH’s system-config-whatever scripts, SELinux… all those things that are not available in Ubuntu.