Feature Request: Systemd services that have a `Nice=` value given explicitly should not be touched by default background priority adjustments

[techsy730]

SystemD allows configuration of services with a Nice property. Which, to little surprise, adjusts the process(es) niceness on launch.

For services that have such a Nice= explicitly given, system76-scheduler shouldn't subject them to the default background priority adjustments. Since in that case the service probably is lower or higher priority for good reason.

(I'm classifying this as a feature request, not a bug, due to the sheer scope of work needed just to "fix" this bug)

For a bit more nuance, we could have

• Services configured with a Nice of <0 should never have their niceness raised above the configured value.
• Services configured with a Nice of >0 should never have their niceness lowered below the configured value (unless it becomes the foreground process...somehow).

IMO, per-process assignments in assignments should override systemd configured niceness by default. Maybe introduce a new config option (false by default) to have systemd managed services still take priority over process assignments.

I don't know of a current (efficient) way to tell the difference between an explicitly set Nice=0 vs the Nice=0 coming from the default of that property (either case shows Nice=0) I'd be fine with treating Nice=0 the same as unset though.

There is a libsystemd crate you can probably use to avoid the pitfalls of parsing command line output.

(If you ever want support for other distros that don't mandate SystemD init, you will probably want to introduce a build configuration option to build without systemd support)

[techsy730]

For "extra credit", also reading the per-user systemd sessions would be nice. But it is kind of tricky to connect to a different user's systemd session.