Soy el administrador de un clúster que se ejecuta en CentOS y uso SLURM para enviar trabajos desde un nodo de inicio de sesión a nodos de cálculo. Recientemente, un usuario se quejó de algún comportamiento inesperado en su trabajo. Si un usuario inicia un trabajo sruny luego cierra la sesión, el trabajo continúa ejecutándose como se esperaba. Sin embargo, cuando el usuario se desconecta debido a un tiempo de espera de SSH, el trabajo finaliza. He replicado este comportamiento eliminando un shell que ejecuta un trabajo kill -1 ShellJobIDy el trabajo se elimina. Examinar los registros de SLURM indica que el trabajo realmente recibió un SIGKILLy no un SIGHUPsegún la línea WSIGTERM 9. Además, si ejecuto kill -1 ActiveSrunJob, los trabajos finalizan con WSIGTERM 9. ¿Qué pasa con el cierre de sesión exitque evita que se cancele el trabajo SLURM? Tenía la impresión, y la investigación parece respaldarlo, que SIGHUPse propaga a los hijos de un caparazón al cerrar sesión. ¿Me estoy perdiendo algo o estoy completamente fuera de lugar?