diff options
Diffstat (limited to 'man/daemon.xml')
| -rw-r--r-- | man/daemon.xml | 22 |
1 files changed, 10 insertions, 12 deletions
diff --git a/man/daemon.xml b/man/daemon.xml index a8bbfc055b..485c66225e 100644 --- a/man/daemon.xml +++ b/man/daemon.xml @@ -180,14 +180,12 @@ functionality of the init system, it is recommended not to execute them when run as new-style service.</para> - <para>Note that new-style init systems guarantee execution of - daemon processes in a clean process context: it is guaranteed - that the environment block is sanitized, that the signal - handlers and mask is reset and that no left-over file - descriptors are passed. Daemons will be executed in their own - session, with standard input/output/error connected to - <filename>/dev/null</filename> unless otherwise configured. The - umask is reset. + <para>Note that new-style init systems guarantee execution of daemon processes in a clean process context: it is + guaranteed that the environment block is sanitized, that the signal handlers and mask is reset and that no + left-over file descriptors are passed. Daemons will be executed in their own session, with standard input + connected to <filename>/dev/null</filename> and standard output/error connected to the + <citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry> + logging service, unless otherwise configured. The umask is reset. </para> <para>It is recommended for new-style daemons to implement the @@ -234,7 +232,7 @@ bus-activatable by supplying a D-Bus service activation configuration file. This has multiple advantages: your daemon may be started lazily on-demand; it may be started in parallel - to other daemons requiring it -- which maximizes + to other daemons requiring it — which maximizes parallelization and boot-up speed; your daemon can be restarted on failure without losing any bus requests, as the bus queues requests for activatable services. See below for @@ -490,13 +488,13 @@ configured address redundant. Another often suggested trigger for service activation is low system load. However, here too, a more convincing approach might be to make proper use of features - of the operating system, in particular, the CPU or IO scheduler + of the operating system, in particular, the CPU or I/O scheduler of Linux. Instead of scheduling jobs from userspace based on monitoring the OS scheduler, it is advisable to leave the scheduling of processes to the OS scheduler itself. systemd - provides fine-grained access to the CPU and IO schedulers. If a + provides fine-grained access to the CPU and I/O schedulers. If a process executed by the init system shall not negatively impact - the amount of CPU or IO bandwidth available to other processes, + the amount of CPU or I/O bandwidth available to other processes, it should be configured with <varname>CPUSchedulingPolicy=idle</varname> and/or <varname>IOSchedulingClass=idle</varname>. Optionally, this may |