<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
- "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
-<!ENTITY % entities SYSTEM "custom-entities.ent" >
-%entities;
-]>
+ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!--
+ SPDX-License-Identifier: LGPL-2.1+
+
This file is part of systemd.
Copyright 2010 Lennart Poettering
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
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
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