mcvic@prcrs.UUCP (David J. McVicar) (05/14/89)
How can a process, while handling a core dumping signal, leave a core file in the current working directory (or other directory, if possible) that is not named 'core'. It is often desirable to have a uniquely named core file, (ex. core.process.pid) for tracking problems and debugging executables in a production environment. I have experimented with signal handlers that will create a "dummy" core file in the current directory when a signal is encountered, then set up a hard link to that core file using the unique name. But, upon process termination, our UNIX kernel (Ultrix 2.2) will always create the "real" core using a different inode number than the "dummy" core inode, resulting in a broken link with the unique name. The problem get's easier when you have a parent process that can come around after a child dies and rename it's childs core, but how can this be done in a process with no parent? Thanks in advance for any responses. mwmwmwmwmwmwmwmwmwmwmwmwmwmwmwm Dave McVicar, PRC Realty Systems, McLean VA mwmwmwmwmwmwmwmwmwmwmwmwmwmwmwm
seindal@skinfaxe.diku.dk (Rene' Seindal) (05/15/89)
mcvic@prcrs.UUCP (David J. McVicar) writes: > How can a process, while handling a core dumping signal, leave > a core file in the current working directory (or other directory, if > possible) that is not named 'core'. It is often desirable to have a > uniquely named core file, (ex. core.process.pid) for tracking problems and > debugging executables in a production environment. I have experimented with > signal handlers that will create a "dummy" core file in the current directory > when a signal is encountered, then set up a hard link to that core file using > the unique name. But, upon process termination, our UNIX kernel (Ultrix 2.2) > will always create the "real" core using a different inode number than the > "dummy" core inode, resulting in a broken link with the unique name. > The problem get's easier when you have a parent process that can > come around after a child dies and rename it's childs core, but how can this > be done in a process with no parent? Here's a little function, that enables a process to dump core on the fly, and continue execution afterwards. It is for 4.3BSD, but it should be easy to adapt it to another system. Coredump are numbered core.1, core.2, ... Not exactly what you asked for, but the idea might be useful. Rene' Seindal (seindal@diku.dk). ------------------------------------------------------------------------ #include <signal.h> #include <stdio.h> #include <sys/wait.h> #define COREFMT "core.%d" int coredump() { static int number = 0; char corename[100]; /* filename: core.number */ register int pid, pid2; union wait status; number++; sprintf( corename, COREFMT, number ); if ( (pid = vfork()) == 0 ) { /* Child */ signal( SIGQUIT, SIG_DFL ); kill( getpid(), SIGQUIT ); sleep(1); /* just for safetys sake */ _exit(0); } if ( pid < 0 ) /* parent resumes after childs death */ return -1; while( (pid2 = wait( &status )) > 0 && pid2 != pid ) ; if ( pid2 < 0 ) /* There were no dead children!! */ return -1; if ( !status.w_coredump ) /* No coredump made */ return -1; if ( rename( "core", corename ) < 0 ) return -1; return number; } ------------------------------------------------------------------------ .TH COREDUMP 3 LOCAL .SH NAME coredump \- make a coredump of the running process. .SH SYNOPSIS int coredump() .SH DESCRIPTION .I coredump will generate a coredump of the running process. It attempts to .IR vfork (2) and make the child dump core. Core dumps are numbered consecutivly, so .I coredump can be called more than once. .SH "RETURN VALUE" .I coredump returns -1 on failure, and the number of the core file if the core was dumped succesfully. Core files are numbered from 1 and up. .SH BUGS If your program has several children, and or uses SIGCHLD to wait for them, it might break, since this routine forks and waits for the child. .SH AUTHOR Ren\'e Seindal, DIKU
riku@field.FI (Riku Kalinen / Systems) (05/16/89)
mcvic@prcrs.UUCP (David J. McVicar) writes: > How can a process, while handling a core dumping signal, leave >a core file in the current working directory (or other directory, if >possible) that is not named 'core'. ... Seems little impossible to me. I used the following workaround, though: When your process cathes something and thinks that it should dump core, do the following: -make directory named, say, core<pid> -cd to that directory -dump core Voila! -riku kalinen, field oy, helsinki, finland -riku@field.fi