I have a user level systemd service running, aka under ~/.config/systemd/user/

but I want to change scheduling policy for this service, in a self-contained way, that is, i want it set on boot, and I don't want to have to do anything on the CLI by hand.

but when I add these two directions under [Serivice]


but I get this issue.

hyegar.service: Control process exited, code=exited, status=214/SETSCHEDULER
  • Does your user account have the privilege to use real-time scheduling? fifo is one of the real-time scheduling policies. To set scheduling policies, you need to either have CAP_SYS_NICE or be root.
    – telcoM
    Commented May 27, 2020 at 7:19
  • @telcoM how can I give my plain user account this ability of CAP_SYS_NICE, programmatically, like in some /etc file rather than some CLI invokation, I dn't want to make this user be root just for this scheduling feature.
    – c-o-d
    Commented May 28, 2020 at 16:15

1 Answer 1


To use the CPUSchedulingPolicy settings, you would have to either be root, or have the CAP_SYS_NICE capability. Unfortunately not all Linux distributions have the capability mechanisms implemented, let alone well documented.

An user level service clearly cannot just specify capabilities for itself, as that would effectively allow any user to become root just by asking for the right capabilities.

The "parent" of your user-level systemd services is an autogenerated system-level service named user@<your-UID>.service. After a bit of experimentation, I found out that you can in fact create an /etc/systemd/system/user@<your-UID>.service.d/override.conf file with contents:


Then, run systemctl daemon-reload, log out, then either reboot or login as another user and ensure that the user@<your-UID>.service from your previous session is no longer active on the system. Now, after logging in again as yourself, all your user account's user-level services should have the CAP_SYS_NICE capability available.

For example, my UID is 1000, so the file I created was named /etc/systemd/system/[email protected]/override.conf and my session includes a gvfs-daemon.service. I'll find out its PID and use /sbin/getpcaps to query its capability status:

$ systemctl --user status gvfs-daemon
● gvfs-daemon.service - Virtual filesystem service
   Loaded: loaded (/usr/lib/systemd/user/gvfs-daemon.service; static; vendor preset: enabled)
   Active: active (running) since Fri 2020-05-29 11:07:28 EEST; 50s ago
 Main PID: 11467 (gvfsd)
   CGroup: /user.slice/user-1000.slice/[email protected]/gvfs-daemon.service
           └─11467 /usr/lib/gvfs/gvfsd
$ /sbin/getpcaps 11467
Capabilities for `11467': = cap_sys_nice+eip

So the capability is now available: Effective, Inheritable and Permitted. This test was performed on Debian 10.

Once the necessary capability is available to your user-level services, unless systemd actively blocks the use of CPUSchedulingPolicy options in user-level services, the CPUSchedulingPolicy options in your user-level service should become effective.

On debian based distros, you can add the AmbientCapabilities to /lib/systemd/system/[email protected] with root so the capabilities can be used by any users' services.

However, you should be aware that CAP_SYS_NICE allows the process with that capability to change the nice values and scheduling policies of any process in the system. That could be used maliciously, either as a denial-of-service attack, or as a way to make any possible race condition with a privileged process easily winnable by an attacker, making it easier for an attacker that already has non-root access to gain root privileges. So you would want to give this capability to trusted users only.

  • WOW - thank you !
    – c-o-d
    Commented May 29, 2020 at 21:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .