Don, > Or can we come up with a way to allow salloc to run as background and > still improve the handling of signals when it has a controlling terminal? > I would be interested in improving this. The main difficulty is, as said, that no one knows what kind of command the 'some-mpi-job' is. It could be interactive, or could be a compiled C program that ends up calling a shell using execve() - there are too many possibilities.
The trick you mentioned is worth looking at. Would it be possible to change the job scripts using input redirection, e.g. #!/bin/bash exec </dev/null salloc -n 16 -N1 mpirun -n 16 <some-mpi-job> & salloc -n yy -Nz mpirun -n yy <other-mpi-job>& On your system it may be that it is ok if salloc leaves orphaned processes behind, we had a case where this should be avoided. > > Yes, it would be possible to use sbatch instead. However, a > > difference between salloc and sbatch is that the sbatch script is > > submitted for execution on one of the nodes of the allocation, > > rather than the command running on the node submitting the request. > > > > You can also bypass the test for "is_interactive" by adding input > > redirection to the salloc: > > > > salloc -n 16 -N 1 mpirun -n 16 <some-mpi-job> </dev/null &
