Aparentemente,mpirun utiliza un controlador SIGINT que "envía" la señal SIGINT a cada uno de los procesos que generó.

Esto significa que puede escribir un controlador de interrupciones para su código habilitado para mpi, ejecutarmpirun -np 3 my-mpi-enabled-executable y luego se planteará SIGINT para cada uno de los tres procesos. Poco después de eso, mpirun sale. Esto funciona bien cuando tienes un pequeño controlador personalizado que solo imprime un mensaje de error y luego sale.sin embargo, cuando su controlador de interrupción personalizado está realizando un trabajo no trivial (por ejemplo, haciendo cálculos serios o datos persistentes), el controlador no se ejecuta hasta su finalización. Supongo que esto se debe a que Mpirun decidió salir demasiado pronto.

Aquí está el stderr al presionarctrl-c (es decir, causando SIGINT) después de ejecutarmy-mpi-enabled-executable. Este es el comportamiento esperado deseable:

interrupted by signal 2.
running viterbi... done.
persisting parameters... done.
the master process will now exit.

Aquí está el stderr al presionarctrl-c despues de ejecutarmpirun -np 1 my-mpi-enabled-executable. Este es el comportamiento problemático:

interrupted by signal 2.
running viterbi... mpirun: killing job...

--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 8970 on node pharaoh exited on signal 0 (Unknown signal 0).
--------------------------------------------------------------------------
mpirun: clean termination accomplished

Respondiendo a cualquier De las siguientes preguntas resolveré mi problema:

¿Cómo anular el controlador SIGINT mpirun (si es posible)?¿Cómo evitar la terminación de los procesos que mpirun generó justo después de que termina mpirun?¿Hay otra señal que mpirun pueda estar enviando a los procesos secundarios antes de que finalice mpirun?¿Hay alguna forma de "capturar" la llamada "señal 0 (señal 0 desconocida)" (vea el segundo stderr arriba)?

Estoy ejecutando openmpi-1.6.3 en linux.