22
journalctl -b | grep Supervising | wc -l
2819

Distro is Fedora 35, vanilla, with PipeWire running the show.

I'm pretty sure all modern Linux distros are affected but people don't care.

There's no rsyslog here and journald doesn't support filtering.

This is getting ridiculous. I can patch it for sure but the question is how it can be done without applying patches and rebuilding. The thing, /usr/libexec/rtkit-daemon, doesn't even have a man page and nothing in its --help offers any clues.

There's a related question which has never been answered as well: rtkit: list threads it is "supervising"?

I can only think of running rtkit-daemon through some wrapper which simply disables all the features related to /dev/log/system logging. Has anyone seen anything like that?

I've filed a bug report just in case.

3
  • 2
    I can't tell if "all modern distros are affected" just that no DAW uses those systemd's thingies. If this helps, but my infos might be dating : you could try adjusting the loglevel v.g add [Service] LogLevelMax=notice into your /lib/systemd/system/rtkit-daemon.service.d/log.conf then systemctl daemon-reload and systemctl restart rtkit-daemon.service.
    – MC68020
    Jan 13, 2022 at 13:39
  • @MC68020 Thanks a lot, it worked, please add it as an answer. Jan 13, 2022 at 22:41
  • This has been fixed in Fedora after my bug report. May 3, 2022 at 18:09

1 Answer 1

25

As Artem rightly wrote, the systemd journal has very limited filtering capabilities. Hence the only solution to limit services or desktop applications verbosity is to organize the filtering earlier in the logging pipeline, before any further processing of any sort.

In order to achieve this for a systemd service :

A/ Locate the directory associated with the service you want to tune. Usually based in (/usr)/lib/systemd/system for services distributed at package's install time such as rtkit-daemon. In this particular case : rtkit-daemon.service.d

B/ Within this directory, (or better in a system-wide configuration subdir /etc/systemd/system/rtkit-daemon.service.d since it won't then be silently removed by further package upgrades) edit or create a log.conf file in order to insert the following statements :

[Service]
LogLevelMax=X

With X standing for the desired numeric loglevel or its associated alphabetical symbol taken from the following list :

  • 0 or emergency, (highest priority messages)
  • 1 or alert,
  • 2 or critical,
  • 3 or error,
  • 4 or warning,
  • 5 or notice,
  • 6 or info
  • 7 or debuginfo (lowest priority messages)

For a given level chosen, logs of all higher levels won't be output. Note that if no loglevel is specified in whatever systemd service .conf file, the loglevel of the daemon defaults to 7, in other words allowing the highest level of verbosity.

Regarding your specific need as worded in the title, LogLevelMax=5 (notice) should suffice (6 as reported in comments).

C/ Save and exit your editor then run the two following commands :

systemctl daemon-reload
systemctl restart rtkit-daemon.service

Nota Bene : Since "New style daemons" (sic)… will be executed in their own session, with standard input connected to /dev/null and standard output/error connected to the systemd-journald.service(8) logging service logging can be achieved via whatever simple (f)print(f). It can then be possible to completely silence the daemon by simply redirecting its stdout and stderr to /dev/null.

While I easily imagine this is not recommended (since wiseness would command to let at least critical errors have their way to syslog), this redirection can be achieved via the following statements :

[Service]
StandardOutput=null
StandardError=null

Credits : Answer based on systemd.exec documentation

5
  • 1
    I suggest to add the log.conf file in /etc/systemd/systemd/rtkit-daemon.service.d/, as this will not fiddle around in package owned directories.
    – marscher
    Feb 11, 2022 at 10:38
  • @marsher 's suggestion is indeed preferable. I amended my answer. Thx.
    – MC68020
    Feb 12, 2022 at 9:54
  • 7
    an even easier way would be to run sudo systemctl edit rtkit-daemon.service and just put those two lines in. no need to fiddle around with finding directories or reloading daemons. still need to restart the service though!
    – Sam Mason
    Mar 15, 2022 at 9:09
  • 6
    Only step B seems to be necessary to solve the problem of rtkit spamming logs. Use @SamMason's sudo systemctl edit rtkit-daemon.service, and it seems to be enough to set LogLevelMax=6. I think step C is dangerous. Don't set the log file to null. What if there are actual errors that need to be attended to?
    – Rizzer
    May 29, 2022 at 19:47
  • 1
    @Rizzer I agree with you. I couldn't successfully set the StandardOutput and StandardError options to any effect. I am running parprouted as a service and the only way to keep it from annihilating syslog is to set LogLevelMax=2. It's just a little too verbose with it's error messages... At least if something "critical" happens then I'll find out about it.
    – Shrout1
    Jul 28, 2022 at 16:36

You must log in to answer this question.

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