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.

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-

Reply via email to