It looks as though I am being outvoted in this, but I would like to make a few more points:
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. 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. 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. 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-
