>> 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. >
I agree, but this is a resource manager, not a shell. My point is that the patch as submitted is in itself consistent and I'd be willing to fix any bug that I may have introduced. If we change the condition for 'is_interactive', then salloc started as a background process is no longer able to provide job control. I tried this scenario (Don's patch + s/WUNTRACED/0/ in the waitpid loop): * starting salloc -N1 & * starts the parent process in the background * the child process (SallocDefaultCommand or login shell) also is in the background * user is stunned and tries 'fg' to bring his child process into the background * however, this only brings salloc into the foreground, not the child process spawned by salloc * the only way out now is 'scancel -u $USER; kill -9 %' * otherwise, typing CTRL-D may end up ending the login shell I find this behaviour more counter-intuitive than the warning message sent to the user "your job is in the background, please place salloc in foreground to continue". It entices users to consider "killall -9 salloc" and scancel as a normal way of ending an interactive session (we have seen this on our system). Gerrit
