mirror of
https://github.com/systemd/systemd.git
synced 2024-11-23 10:13:34 +08:00
docs: fix typo in filename: REATLIME -> REALTIME
This commit is contained in:
parent
9959681a0d
commit
a65b864835
2
TODO
2
TODO
@ -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
|
||||||
|
@ -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?**
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user