Inspect and Change Linux Scheduling with chrt

You will finish with a safe way to inspect a process's scheduling policy, check the valid priority range, and change a process when you have the required privilege. The examples use the installed chrt from util-linux 2.41.3. The local man page is generated from util-linux 2.39.3, so this guide calls out the version difference where it can affect troubleshooting.

Allow about fifteen minutes. You need a shell and the util-linux package. Reading a process's scheduling attributes is normally unprivileged. Changing them can affect latency and CPU access, and the local man page says it requires CAP_SYS_NICE, usually obtained through sudo. Test on a short-lived process before touching a service.

1. Confirm the binary and its version

Start by checking which executable will run. This is read-only and does not need elevated privileges:

$ command -v chrt
/usr/bin/chrt
$ chrt --version
chrt from util-linux 2.41.3
$ dpkg-query -S "$(command -v chrt)"
util-linux: /usr/bin/chrt

The version reported by the executable is the useful reference for its option syntax. On this machine, the installed package metadata and the compressed man page describe util-linux 2.39.3, while the executable reports 2.41.3. If your output differs, read the man page installed alongside your executable and test the exact command you plan to use.

Checkpoint: command -v should identify the binary you intended. An unexpected path can explain a mismatch between help text, package metadata and behaviour.

2. Check scheduler policies and priority ranges

Use -m to ask chrt for the minimum and maximum valid priority for each policy:

$ chrt -m
SCHED_OTHER min/max priority  : 0/0
SCHED_FIFO min/max priority   : 1/99
SCHED_RR min/max priority     : 1/99
SCHED_BATCH min/max priority  : 0/0
SCHED_IDLE min/max priority   : 0/0
SCHED_DEADLINE min/max priority : 0/0

Spacing varies with the util-linux build, but the values are the important part. SCHED_FIFO and SCHED_RR use priorities from 1 to 99 here. The other listed policies use priority zero. Do not infer that a larger number is always better: real-time policies can take CPU time from ordinary work and can make a host difficult to manage.

The default Linux policy is SCHED_OTHER. The command's policy option defaults to SCHED_RR when you explicitly use a priority-setting form without selecting another policy, according to the local man page. Select a policy deliberately instead of relying on that default.

3. Inspect an existing process

Every process has a numeric PID. Start a harmless process, retain its PID, and ask chrt to read its policy:

$ sleep 30 &
[1] 4036041
$ child=$!
$ chrt -p "$child"
pid 4036041's current scheduling policy: SCHED_OTHER
pid 4036041's current scheduling priority: 0
$ kill "$child"
$ wait "$child" 2>/dev/null || true

The job number and PID will differ. -p means operate on an existing PID rather than launching a new command. Reading the result is an ordinary operation, so try it before adding sudo. A missing or exited PID produces an error because there is no process left to inspect.

To inspect every thread belonging to a process, add -a. This matters for multithreaded programs because scheduling attributes are associated with tasks, not just the label you see in a process list:

$ chrt -a -p "$PID"
# one line of policy and priority information per task may be printed

Replace PID with a real numeric process ID. Do not copy a PID from an old listing without checking that the process still exists; PIDs are reused.

4. Run one command with an explicit policy

The non--p form launches a command with the requested priority and arguments. For an ordinary, unprivileged smoke test, use SCHED_OTHER and priority zero:

$ chrt --other 0 /usr/bin/printf '%s\n' 'scheduled-child-ok'
scheduled-child-ok
$ printf 'exit status: %s\n' "$?"
exit status: 0

The child inherits the selected scheduling attributes for its lifetime. Keep the command path and its arguments after the priority. Quote values that may contain spaces or shell metacharacters. The exit status shown above is the child command's status; it does not prove that a real-time policy would be suitable for your workload.

For a policy change that needs real-time priority, use a deliberate test command and expect a permission failure unless the invoking account has CAP_SYS_NICE:

$ chrt --rr 10 /usr/bin/true
chrt: failed to set pid 0's policy: Operation not permitted
$ printf 'exit status: %s\n' "$?"
exit status: 1

Error wording and the PID can vary. If you are authorised to make the change, repeat the exact command with sudo. Do not use elevated privileges as a first diagnostic for a typo or an invalid priority.

5. Change and then restore a process

Changing a live process is service-disrupting enough to require a rollback plan. First record its current state:

$ chrt -p "$PID"
pid 12345's current scheduling policy: SCHED_OTHER
pid 12345's current scheduling priority: 0

For a permitted test, set round-robin scheduling at priority 10:

$ sudo chrt --rr --pid 10 "$PID"
$ chrt -p "$PID"
pid 12345's current scheduling policy: SCHED_RR
pid 12345's current scheduling priority: 10

The local man page's set form is chrt -r -p priority PID. The long options make the roles clearer, but use the form supported by the installed help output. To restore the ordinary Linux default, set SCHED_OTHER with priority zero:

$ sudo chrt --other --pid 0 "$PID"
$ chrt -p "$PID"
pid 12345's current scheduling policy: SCHED_OTHER
pid 12345's current scheduling priority: 0

Changing a process does not create a persistent configuration file. The setting lasts only while that process or task exists, unless a service manager, wrapper or application applies it again. If the process is supervised, fix the source of the setting as well or the supervisor may reapply it on restart.

6. Avoid the common traps

• Wrong priority: SCHED_OTHER, SCHED_BATCH and SCHED_IDLE require zero here. Real-time policies require a value in the range reported by chrt -m.
• Wrong target: -p operates on a PID and does not launch a command. Without -p, the next arguments describe a command to run.
• Missing privilege: reading is available to ordinary users, but setting attributes requires CAP_SYS_NICE. A non-zero status is a failed change, not a partial success.
• Thread mismatch: use -a when the application has multiple tasks and you need all of them changed or inspected.
• Deadline policy: SCHED_DEADLINE is specialised. The local man page requires at least a period and describes runtime less than or equal to deadline less than or equal to period. Do not experiment on a production host without understanding sched(7) and having a recovery path.

Use --verbose when a successful operation needs status information. It reports what chrt is doing; it does not grant permission or validate that a real-time choice is safe for the workload.