Is `rtkit-daemon` actually necessary on a non-realtime system?

webninja · 2024-12-28 04:57:39

My system logs are full of these errors:

$ systemctl status rtkit-daemon
● rtkit-daemon.service - RealtimeKit Scheduling Policy Service
     Loaded: loaded (/usr/lib/systemd/system/rtkit-daemon.service; disabled; preset: disabled)
     Active: active (running) since Thu 2024-12-26 23:57:17 EST; 23h ago
 Invocation: 0c75a17f18854532b74f10bdbfd97432
   Main PID: 750 (rtkit-daemon)
      Tasks: 3 (limit: 18675)
     Memory: 596K (peak: 1.7M)
        CPU: 404ms
     CGroup: /system.slice/rtkit-daemon.service
             └─750 /usr/lib/rtkit-daemon

Dec 27 20:00:04 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 20:00:04 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 20:24:42 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 20:36:29 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 20:45:02 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 21:24:26 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 21:32:42 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 21:36:21 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 22:20:52 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted
Dec 27 22:21:10 x1 rtkit-daemon[750]: Failed to make ourselves RT: Operation not permitted

At first, I couldn't figure out what this obscure service actually does on my system. It's package description is "Realtime Policy and Watchdog Daemon".

Some research led me to this comment on this forum, which explains that it is used by pipewire and pulseaudio and has a link to the project page.

The project's readme explains that it serves as a safe avenue for processes to request real-time scheduling without being able to freeze the system.

I'm running a custom kernel with real-time capabilities switched off (I have CONFIG_PREEMPT_RT=n).

Is rtkit in any way necessary on a system that is not actually capable of real-time scheduling?

webninja · 2024-12-28 05:19:57

Oh, I see that 'rtkit' ended up installed because it is listed as required by `xdg-desktop-portal`, which in turn is necessary for screen capture with pipewire:

$ pactree -r rtkit
rtkit
└─xdg-desktop-portal
  └─xdg-desktop-portal-wlr

webninja · 2025-01-09 00:19:35

I did some personal investigation and it looks like rtkit is specified as a required dependency by the xdg-desktop-portal package simply because xdg-desktop-portal itself doesn't list it as optional.

Looking at the code for xdg-desktop-portal proper, it looks like the absence of rtkit does nothing to impair its functionality.

In fact, uninstalling the rtkit package on my system simply resulted in different messages being generated in the system logs.

I therefore posted a comment upstream at the xdg-desktop-portal project proposing the idea of officially making rtkit an optional dependency

Lone_Wolf · 2025-01-09 11:27:00

pulseaudio also requires rtkit .

zse · 2025-01-09 17:24:02

fyi, rtkit is about giving threads realtime priority, which is completely independent of the CONFIG_PREEMPT* kernel setting, that is possible in any kernel configuration (afaik). It makes sense to give audio threads high priority to avoid drop-outs/crackling, but rtkit is a kludge around missing user privileges, with the right system configuration it should not be needed.

twelveeighty · 2025-01-10 15:57:48

I am trying to figure out how to suppress these rtkit entries that are spamming my journal (there's 2 entries every minute or so):

rtkit-daemon[1140]: Supervising 7 threads of 4 processes of 1 users.

Assuming the "Upstream URL" is valid in the PKGBUILD, it appears these come from rtkit-daemon.c and are supposed to be only debug messages.

----------- rtkit/rtkit-daemon.c

        syslog(LOG_DEBUG, "Supervising %u threads of %u processes of %u users.\n",
                n_total_threads,
                n_total_processes,
                n_users);

#ifdef HAVE_LIBSYSTEMD
        sd_notifyf(0,
                   "STATUS=Supervising %u threads of %u processes of %u users.",
                   n_total_threads,
                   n_total_processes,
                   n_users);
#endif

I think this explains the duplication. Does anyone know a way to suppress these messages in the journal through configuration? If possible, I'd like to suppress BOTH the syslog(LOG_DEBUG,... AND the sd_notifyf(0,...

Niinu · 2025-01-14 18:27:54

twelveeighty wrote:

Does anyone know a way to suppress these messages in the journal through configuration? If possible, I'd like to suppress BOTH the syslog(LOG_DEBUG,... AND the sd_notifyf(0,...

This method worked for me:

You can change the service unit’s log level. To do so:

    Edit the unit:

sudo systemctl edit rtkit-daemon.service

    In the [Service] section, add:

LogLevelMax=3

    For reference, the standard log levels are emergency (0), alert (1), critical (2), error (3), warning (4), notice (5), info (6), and debug (6). Setting a lower number excludes the higher and less important log messages from your journal.

Afterwards, save and exit followed by loading the changes, and r3estarting the unit:

sudo systemctl daemon-reload

and

sudo systemctl restart rtkit-daemon.service

source: https://forum.manjaro.org/t/rtkit-daemon-spam/129533/3

twelveeighty · 2025-01-15 15:45:45

@Niinu - does that suppress BOTH lines of "Supervising..." in the logs? I can't tell from the documentation if LogLevelMax in the unit config can suppress the "STATUS=" message in sd_notifyf(). Right now, I'm running a patched version of rtkit where I removed those lines altogether.

Niinu · 2025-01-15 19:20:24

twelveeighty wrote:

@Niinu - does that suppress BOTH lines of "Supervising..." in the logs? I can't tell from the documentation if LogLevelMax in the unit config can suppress the "STATUS=" message in sd_notifyf(). Right now, I'm running a patched version of rtkit where I removed those lines altogether.

With LogLevelMax=6 / LogLevelMax=info there's no Supervising logs at all for me, but rtkit-daemon still prints the below when launching new programs:
Successfully made thread x of process y owned by '1000' RT at priority 10.

With LogLevelMax=5 / LogLevelMax=notice neither the Supervising logspam nor the Succesfully made thread get printed.

I wasn't able to discern any consistency in the amount of the supervising lines.

twelveeighty · 2025-01-15 19:46:31

        syslog(LOG_INFO, "Successfully made thread %llu of process %llu owned by '%s' RT at priority %u.\n",
        ...

That makes sense, since it's logged at LOG_INFO (4), which would be suppressed at notice (5). That's great, I'll go back to the original rtkit and try your log configs, that would be much better than running a hacked version.

Edit: for reference, I added a section to the systemd Wiki for setting LogLevelMax in [Service].

Last edited by twelveeighty (2025-01-16 14:58:11)

Arch Linux

#1 2024-12-28 04:57:39

Is `rtkit-daemon` actually necessary on a non-realtime system?

#2 2024-12-28 05:19:57

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#3 2025-01-09 00:19:35

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#4 2025-01-09 11:27:00

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#5 2025-01-09 17:24:02

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#6 2025-01-10 15:57:48

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#7 2025-01-14 18:27:54

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#8 2025-01-15 15:45:45

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#9 2025-01-15 19:20:24

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

#10 2025-01-15 19:46:31

Re: Is `rtkit-daemon` actually necessary on a non-realtime system?

Board footer