I have added a note in the salloc man page with the work-around described by
Gerrit:
NOTE: The salloc logic includes support to save and restore the
terminal line settings and is
designed to be executed in the foreground. If you need to execute salloc
in the background, set its
standard input to some file, for example: "salloc -n16 a.out </dev/null
&"
________________________________________
From: [email protected] [[email protected]] On Behalf
Of Gerrit Renker [[email protected]]
Sent: Monday, February 07, 2011 10:55 PM
To: [email protected]
Subject: Re: [slurm-dev] Change in "salloc" to inhibit running in background?
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 &
