15

On a shared server, I would like to have some very low priority users such that whenever an other user (also without root privileges) needs the resources, they can kill any of the low priority users' processes.

Is it possible to allow something like that?

|improve this question|||||
  • 1
    Give sudo -u user kill right to all user needed possibly in a group – Kiwy Jul 4 '18 at 6:47
  • 4
    I really hope these low priority users are actual human users, and you and your buddies are pure-bred BOFHs. It makes the question much more intriguing. – pipe Jul 4 '18 at 15:06
  • @DavidFoerster, one issue is that even when the CPU is not at 100% low priority process can fill up the processor cache etc. Likewise with disk access etc. – Ian Ringrose Jul 5 '18 at 10:14
24

Give the other users permission to kill the processes as the low priority user through

sudo -u lowpriouser /bin/kill PID

A user can only signal their own processes, unless they have root privileges. By using sudo -u a user with the correct set-up in the sudoers file may assume the identity of the low priority user and kill the process.

For example:

%killers ALL = (lowpriouser) /bin/kill

This would allow all users in the group killers to run /bin/kill as lowpriouser.

See also the sudoers manual on your system.

On an OpenBSD system, the same can be done through the native doas utility with a configuration like

permit :killers as lowpriouser cmd /bin/kill

Then

doas -u lowpriouser /bin/kill PID

See the manuals for doas and doas.conf.

|improve this answer|||||
  • If you allow any kill command, you could abuse it to send signals unrelated to termination to arbitrary processes, which can be a security concern. – forest Jul 5 '18 at 2:56
  • @forest This is why I don't suggest giving everyone the ability to use the root account to run kill. Note too that I suggest using a user group (killers), not all users. – Kusalananda♦ Jul 5 '18 at 5:52
  • But what I mean is, that would allow that group to send kill -HUP, not just kill -TERM. – forest Jul 5 '18 at 6:41
  • @forest Yes. It allows sending signals to processes owned by lowpriouser. If you want to restrict the signals to TERM, then write a wrapper shell script around /bin/kill and allow people to use that instead of /bin/kill. – Kusalananda♦ Jul 5 '18 at 6:46
  • 1
    %killers ALL = (lowpriouser) /bin/kill -(9, 15) [0-9 ]* – forest Jul 5 '18 at 7:04
5

You shouldn't kill the processes, if they're low priority they'll consume few resources.

To actually make them low priority, either change their priority manually, or use a daemon like autonice that I wrote for DEC OSF/1 many years ago (c. 1994) that looks for long-running jobs and progressively reduces their priority the longer they run.

EDIT there's a package called and that offers this functionality for modern Unices.

|improve this answer|||||
  • one issue is that even when the CPU is not at 100% low priority process can fill up the processor cache etc. Likewise with disk access etc – Ian Ringrose Jul 5 '18 at 10:15
  • @IanRingrose only tasks that have been scheduled to run can occupy cache or perform disk accesses. – Alnitak Jul 5 '18 at 14:36
4

I think you approach the issue from the wrong angle: If a process is run at low priority settings (CPU, I/O) it shouldn't affect other processes much because it won't be scheduled to run. As for memory usage, if main memory is tight and the process wasn't scheduled to run in a long time (e. g. due to CPU and I/O constraints), its “clean” pages are dropped and its “dirty” pages are committed or swapped out and no longer affect the performance of other processes.

Conclusion: with the right priority setting and sufficient swap space it should be unnecessary to kill low priority jobs to make “room“ for more important tasks; instead the kernel will take care to put the former to sleep in favour of the latter.

|improve this answer|||||
  • 1
    "Low priority" could just as well mean "not important" without the implied meaning "running at decreased CPU priority". This is not made explicit in the question though. – Kusalananda♦ Jul 4 '18 at 18:39
  • @Kusalananda: I agree that this is not explicit in the question, but my answer states that it should be in reality. – David Foerster Jul 4 '18 at 18:43
  • 1
    It’s not that simple though. Even a low-priority process can stall the system, especially if it has memory constraints: depending on how those are set up, it will make the process swap. Swapping causes I/O (which may not be included in the I/O quota of the process) and it will also make the system less responsive by orders of magnitude. Then you’d probably also want that in general (while others don’t need the resources), the low-priority process can actually get all the resources it needs (which makes typical memory limits inapplicable). CPU shares help here. – Jonas Schäfer Jul 5 '18 at 9:14
  • @JonasWielicki, the old "unix way" of swapping out complete process did have its advantage. If I recall correctly HPUX can some tools to solve this problem in the 1990s. – Ian Ringrose Jul 5 '18 at 10:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.