Higher priority for root processes
 

Hello,
I need to set a higher priority for sshd and sshguard processes, but I can’t find a way. On my server, there are 2 types of users (faculty and student with corresponding groups) plus the root. Moreover, I need a realtime group.

Users from group faculty (also student, if needed) need to be able to ssh even if the server RAM is almost full.

Here is my limits.conf:

However, at startup processes from faculty run with default priority 10 and niceness -10, while root processes run with default priority 20 and niceness 0.

How can I make root processes run with default priority lower than other groups?

Probably you need rebuild or even patch kernel to achieve support for real time processes. Higher priority for daemon process? Why do you need that? Something with ssh connection? Do you have thousands ssh connections per second?

The server is mainly used for scientific experiments and it happens that some user fills the RAM, making it impossible to log in. I'm still trying to set up nohang or another oom-killer properly, but in the meanwhile, it would be useful to be able to access the server when problems occur, so that I can understand why nohang is not killing processes...

In general, I want to be able to access the server in any circumstance, because it's almost the only way to log in.

f

There is quotas system - at least for storage - maybe there are quotas for memory and other resources Maybe try to ask for batch mode rather than interactive - someone can run its app - at night? But I don't see how lack of RAM may influence system response. System is using swap. Stacking - procedure calls - can dramatically slow system. This behavior is something new? Keep open connection all the time. As common user. You can always sudo or su.

It is ulimit and you can set per user values like # processes, memory, etc. It is sometimes set
in /etc/security/limits.conf. Go "man ulimit".

You can obviously set a high watermark to prevent a single user or process hogging memory.



Here is a tutorial:


https://www.networkworld.com/article...th-ulimit.html

Then fix the problem, not the symptom.
Trying to define in advance what (who) can be not killed is likely to get political. I take the opposite approach in a different environment. When I'm doing benchmarks, everything other than my terminal session runs in a single control group with the resources I define. I get the rest (not much but enough) to ensure I can monitor uninterrupted. You could do similar, and as suggested above, keep your ssh session active but disconnected so you can re-connect later when you need to investigate. Won't help anyone else but in the investigation stage that's probably what's needed.

Like I said, politics means the world is likely crash down on you if this gets out. :shrug:

renice(1) might be used to tweak the scheduling priority of sshd process. But this is a hammer instead of a scalpel: everyone's ssh connection is affected.

In my experience, though, this seems like more of an "insufficient swap space" or "process ulimit" problem than one about daemon scheduling priorities. Once a user has sshed into the system and grabbed all available memory, I'm not certain how having modified the priority of sshd would help. Raising the priority of the sshd process is no guarantee that someone will be able to get onto the system when the system is completely starved of available RAM.

The output of free(1) would be interesting to see.

I agree with rnturn's assessments. Fiddling with process priorities won't help you here. Your system is becoming over-committed and so it is "thrashing."

As others have noted, the ulimit command can be used to prevent user processes from commanding too much memory, but this is only partially useful if your system is thrashing. You might simply need more hardware, particularly RAM. ("Chips are cheap ... splurge.")