docs: fix typo in filename: REATLIME -> REALTIME

This commit is contained in:
Yu Watanabe 2024-09-17 15:13:38 +09:00 committed by Lennart Poettering
parent 9959681a0d
commit a65b864835
3 changed files with 2 additions and 2 deletions

2
TODO
View File

@ -1860,7 +1860,7 @@ Features:
* fstab-generator: default to tmpfs-as-root if only usr= is specified on the kernel cmdline * fstab-generator: default to tmpfs-as-root if only usr= is specified on the kernel cmdline
* docs: bring https://systemd.io/MY_SERVICE_CANT_GET_REATLIME up to date * docs: bring https://systemd.io/MY_SERVICE_CANT_GET_REALTIME up to date
* add a job mode that will fail if a transaction would mean stopping * add a job mode that will fail if a transaction would mean stopping
running units. Use this in timedated to manage the NTP service running units. Use this in timedated to manage the NTP service

View File

@ -104,7 +104,7 @@ A: Use:
**Q: Whenever my service tries to acquire RT scheduling for one of its threads this is refused with EPERM even though my service is running with full privileges. This works fine on my non-systemd system!** **Q: Whenever my service tries to acquire RT scheduling for one of its threads this is refused with EPERM even though my service is running with full privileges. This works fine on my non-systemd system!**
A: By default, systemd places all systemd daemons in their own cgroup in the "cpu" hierarchy. Unfortunately, due to a kernel limitation, this has the effect of disallowing RT entirely for the service. See [My Service Can't Get Realtime!](/MY_SERVICE_CANT_GET_REATLIME) for a longer discussion and what to do about this. A: By default, systemd places all systemd daemons in their own cgroup in the "cpu" hierarchy. Unfortunately, due to a kernel limitation, this has the effect of disallowing RT entirely for the service. See [My Service Can't Get Realtime!](/MY_SERVICE_CANT_GET_REALTIME) for a longer discussion and what to do about this.
**Q: My service is ordered after `network.target` but at boot it is still called before the network is up. What's going on?** **Q: My service is ordered after `network.target` but at boot it is still called before the network is up. What's going on?**