On Sat, 12 Feb 2011 09:10:04 -0800, Gerrit Renker <[email protected]> wrote: > >> 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.
Agreed. I don't feel too strongly about my prior position, and I think you have pretty much convinced me. (But I think a good idea would be to add a detailed comment in the code to this fact, so we don't forget why the test is there) mark > 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 >
