* remote core dumping / just in time debugging
@ 2001-09-25 22:57 Dan Kegel
0 siblings, 0 replies; only message in thread
From: Dan Kegel @ 2001-09-25 22:57 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
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 (kjahds@kjahds.com)'s post "Re: core files" on 1999/01/01
http://groups.google.com/groups?hl=en&selm=fa.m8ig46v.1b2q89r%40ifi.uio.no ,
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.
Comments?
- Dan
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2001-09-25 22:57 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-09-25 22:57 remote core dumping / just in time debugging Dan Kegel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox