On Sat, 12 Feb 2011 07:09:54 -0800, Gerrit Renker <[email protected]> wrote: > I tried the patch below. It works for the case where salloc is run with > a non-interactive command to execute > > gele1:0 git>./src/salloc/salloc -N1 /bin/date -R & > [1] 10313 > gele1:0 git>salloc: Granted job allocation 214 > Sat, 12 Feb 2011 15:40:33 +0100 > salloc: child process '/bin/date' exited with status=0 > salloc: Relinquishing job allocation 214 > salloc: Job allocation 214 has been revoked. > > but since salloc is no longer able to become the terminal foreground process, > any interactive session is started in stopped state: > > gele1:0 git>./src/salloc/salloc -N1 /bin/csh & > [1] 10307 > gele1:0 git>salloc: Granted job allocation 212 > salloc: child process '/bin/csh' exited with status=5503 > salloc: Relinquishing job allocation 212 > salloc: Job allocation 212 has been revoked. > > gele1:0 git>./src/salloc/salloc -N1 & # login shell > (/usr/local/bin/bash) > [1] 10310 > gele1:0 git>salloc: Granted job allocation 213 > salloc: child process '/usr/local/bin/bash' exited with status=5503 > salloc: Relinquishing job allocation 213 > salloc: Job allocation 213 has been revoked. > > The 'status' line is the wait(2) status returned by the child process, > with WIFSTOPPED(status) = 1 and WSTOPSIG(status) = SIGTTIN, i.e. the > child process already starts in the stopped state. > > That was what I asked in the first reply - if starting an interactive session > via salloc, > why would a user want to start it in a stopped state.
That is a good point, but it goes equally for starting an interactive process outside of salloc(1) as well. My humble opinion would be to allow users to start salloc(1) in the background, and that they will learn quickly not to do this for interactive processes, just as they do for any other utilities they invoke from the shell. mark > Gerrit > > > On Fri, 11 Feb 2011 11:54:11 -0700 [email protected] wrote: > > Gerrit and Moe, > > > > Suppose we change the "is_interactive" test to allow us to have it both > > ways? Consider the following patch (against version 2.2.1): > > > > Index: salloc.c > > =================================================================== > > RCS file: /cvsroot/slurm/slurm/src/salloc/salloc.c,v > > retrieving revision 1.1.1.40 > > diff -u -r1.1.1.40 salloc.c > > --- salloc.c 28 Jan 2011 17:45:59 -0000 1.1.1.40 > > +++ salloc.c 11 Feb 2011 16:06:16 -0000 > > @@ -162,19 +162,8 @@ > > static char *msg = "Slurm job queue full, sleeping and retrying."; > > slurm_allocation_callbacks_t callbacks; > > > > - is_interactive = isatty(STDIN_FILENO); > > + is_interactive = isatty(STDIN_FILENO) && (tcgetpgrp(STDIN_FILENO) > > == (pid = getpgrp())); > > if (is_interactive) { > > - bool sent_msg = false; > > - /* Wait as long as we are running in the background */ > > - while (tcgetpgrp(STDIN_FILENO) != (pid = getpgrp())) { > > - if (!sent_msg) { > > - error("Waiting for program to be placed in > > " > > - "the foreground"); > > - sent_msg = true; > > - } > > - killpg(pid, SIGTTIN); > > - } > > - > > /* > > * Save tty attributes and reset at exit, in case a child > > * process died before properly resetting terminal. > > > > > > This change allows salloc to run in the background if requested, but > > still preserves the tty attributes of the terminal if the process is > > running in the foreground. It also avoids having to use the "trick" of > > using input redirection (</dev/null) in order to fool the code, and keeps > > the original semantics of salloc for those who use it to, for example, > > launch an xterm or run jobs using mpirun. And we don't have to change > > the documentation, either. > > > > -Don Albert- >
