Hi, I come a little bit late on that but I would like to add that I agree with Don on that.
IMHO, modifing such a behavior is not really great. There is more scenarios where salloc is executing a non-interactive command (salloc/mpirun) in background than scenarios where it is running a particular shell interactively _starting_ in background. If it is mandatory to have this behavior for interactive application I would rather have a new option for salloc to use this mode that making it the default. At least for me, 99% of the backgrounded salloc are made for mpirun executions in non regression tests, I am not sure that my users will be happy to rewrite all their scripts or python programs that launches concurrent salloc/mpirun using threads (automatically set in background by python). Would it be possible to make it configurable ? Regards, Matthieu 2011/2/15 <[email protected]> > > It looks as though I am being outvoted in this, but I would like to make a > few more points: > > 1. The reason I got involved in this was that a rather large Bull > customer has acceptance test script jobs that submit thousands of "salloc" > requests as background jobs. These scripts worked just fine, and then > they were broken by a change that appeared in the final version of 2.2.0, > with no explanation of why salloc is suddenly restricted to running in the > foreground. > 2. I understand that there are job control issues with salloc when run > in the background, and that the changes in signal handling that Gerrit > made > improve the situation when salloc is run in the foreground by retaining > better control of the job from the terminal, but I disagree that this is > sufficient justification to remove the ability to run salloc in the > background, expecially since this change can be trivially bypassed by > using > input redirection. All that has been accomplished is to break the scripts > I > mentioned above and whatever else depended on the current behavior of > salloc, and force users to add a "kludge" to obtain the behavior they had > before. The customer scripts above have a legitimate use in invoking > "non-interactive" usage of salloc, as do other examples such as starting > an > "xterm" on a SLURM allocation. > 3. I disagree that the proposed comments in the code provide > sufficient explanation of this change. The new comments explain that > salloc > must be running in the foreground to issue the "tcsetpgrp" call and run > "interactive" subprocesses, but they do not explain the rationale for > disallowing salloc to run in the background when it is running only > "non-interactive" subprocesses. > 4. The test case for my patch of submitting an interactive shell as a > background job request is spurious. As Gerrit said, "if starting an > interactive session via salloc, why would a user want to start it in a > stopped state"? The answer is: you wouldn't. If you wanted to run > interactively, you wouldn't add that "&" at the end of your command. But > if you knew that you wanted to run something that would run > "non-interactively", such as an "mpirun" or an "xterm", why would you > not want to be able to add that "&", and free up your terminal or script > for other commands? As Mark noted previously, if users inadvertently > try > to run jobs that need to be interactive in the background, they should > fairly quickly learn that it isn't a good idea, whether under salloc or > just a normal shell. > > > Ok, I've had my say. I will rest my case now. > > -Don Albert- >
