[lkml]   [2001]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectremote core dumping / just in time debugging
I am looking at adding a hook to the kernel to allow
core dumps to go somewhere other than ./core.

Initially, I'm looking into allowing core to be a fifo (yeah, it's a
hack, but supposedly it worked on solaris in 1998), but later I'll
want to be able to set a default coredump handler for all processes.

Looking at previous discussion on the topic, e.g.
Kenneth Albanowski ('s post "Re: core files" on 1999/01/01 ,
the scheme that comes to mind is:

When the kernel wants to dump core on a process, it opens the fifo
/dev/coredumper and writes the pid of the process to the fifo, then
puts the process to sleep. On error, no fifo, or fifo still full after
a couple minutes, it dumps core as before.

The process listening to /dev/coredumper reads the pid, then opens a fd
to where it wants the core to be dumped to, then uses ptrace
to request a core dump of the given pid to the given fd.
The fd may be a normal file, or a socket or fifo (in which case the
kernel uses padding rather than seeking to page boundaries).

Security is maintained because /dev/coredumper can be owned by root and chmod 600,
and because the daemon reading from it must have privs to use ptrace on
the given process.

This would allow just-in-time debugging as well as remote core dumping.

- Dan
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.034 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site