2010-04-23 22 views
6

¿Hay alguna forma de configurar el directorio donde se colocan los archivos de volcado del núcleo para un proceso específico?por proceso directorio de volcado del núcleo configurable

Tengo un proceso de daemon escrito en C++ para el que me gustaría configurar el directorio de volcado del núcleo. Opcionalmente, el patrón de nombre de archivo también debe ser configurable.

Sé acerca de /proc/sys/kernel/core_pattern, sin embargo, esto cambiaría el patrón y la estructura de directorios globalmente.

Apache tiene la directiva CoreDumpDirectory - por lo que parece ser posible.

Respuesta

14

No, no puede configurarlo por proceso. El archivo central se descarga al directorio de trabajo actual del proceso o al directorio establecido en/proc/sys/kernel/core_pattern si el patrón incluye un directorio.

CoreDumpDirectory en apache es un hack, apache registra manejadores de señal para todas las señales que causan un volcado del núcleo, y cambia el directorio actual en su manejador de señal.

/* handle all varieties of core dumping signals */ 
static void sig_coredump(int sig) 
{ 
    apr_filepath_set(ap_coredump_dir, pconf); 
    apr_signal(sig, SIG_DFL); 
#if AP_ENABLE_EXCEPTION_HOOK 
    run_fatal_exception_hook(sig); 
#endif 
    /* linuxthreads issue calling getpid() here: 
    * This comparison won't match if the crashing thread is 
    * some module's thread that runs in the parent process. 
    * The fallout, which is limited to linuxthreads: 
    * The special log message won't be written when such a 
    * thread in the parent causes the parent to crash. 
    */ 
    if (getpid() == parent_pid) { 
     ap_log_error(APLOG_MARK, APLOG_NOTICE, 
        0, ap_server_conf, 
        "seg fault or similar nasty error detected " 
        "in the parent process"); 
     /* XXX we can probably add some rudimentary cleanup code here, 
     * like getting rid of the pid file. If any additional bad stuff 
     * happens, we are protected from recursive errors taking down the 
     * system since this function is no longer the signal handler GLA 
     */ 
    } 
    kill(getpid(), sig); 
    /* At this point we've got sig blocked, because we're still inside 
    * the signal handler. When we leave the signal handler it will 
    * be unblocked, and we'll take the signal... and coredump or whatever 
    * is appropriate for this particular Unix. In addition the parent 
    * will see the real signal we received -- whereas if we called 
    * abort() here, the parent would only see SIGABRT. 
    */ 
} 
Cuestiones relacionadas