mirror of
https://github.com/systemd/systemd.git
synced 2025-03-03 16:58:37 +03:00
man: more grammar improvements
- place commas - expand contractions (this is written prose :) - add some missing words
This commit is contained in:
Jan Engelhardt
Zbigniew Jędrzejewski-Szmek
parent
337fa161c4
commit
409dee2e44
@ -72,7 +72,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>Samples=500</varname></term>
|
||||
<listitem><para>Configure the amount of samples to
|
||||
record total before bootchart exits. Each sample will
|
||||
record in total before bootchart exits. Each sample will
|
||||
record at intervals defined by Frequency=.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -107,7 +107,7 @@
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>Output=[path]</varname></term>
|
||||
<listitem><para>Configures the output folder for writing
|
||||
<listitem><para>Configures the output directory for writing
|
||||
the graphs. By default, bootchart writes the graphs to
|
||||
<filename>/run/log</filename>.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -124,7 +124,7 @@
|
||||
<varlistentry>
|
||||
<term><varname>PlotMemoryUsage=no</varname></term>
|
||||
<listitem><para>If set to yes, enables logging and graphing
|
||||
of processes PSS memory consumption.</para></listitem>
|
||||
of processes' PSS memory consumption.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
|
||||
@ -56,26 +56,27 @@
|
||||
and hand control over to a boot loader stored on a
|
||||
persistent storage device. This boot loader will then
|
||||
invoke an OS kernel from disk (or the network). In the
|
||||
Linux case this kernel (optionally) extracts and
|
||||
executes an initial RAM disk image (initrd) such as
|
||||
<citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
Linux case, this kernel (optionally) extracts and
|
||||
executes an initial RAM disk image (initrd), such as
|
||||
generated by
|
||||
<citerefentry><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
|
||||
which looks for the root file system (possibly using
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
for this). After the root file system is found and
|
||||
mounted the initrd hands over control to the host's
|
||||
mounted, the initrd hands over control to the host's
|
||||
system manager (such as
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
|
||||
stored on the OS image which is then responsible for
|
||||
stored on the OS image, which is then responsible for
|
||||
probing all remaining hardware, mounting all necessary
|
||||
file systems and spawning all configured
|
||||
services.</para>
|
||||
|
||||
<para>On shutdown the system manager stops all
|
||||
<para>On shutdown, the system manager stops all
|
||||
services, unmounts all file systems (detaching the
|
||||
storage technologies backing them), and then
|
||||
(optionally) jumps back into the initrd code which
|
||||
unmounts/detaches the root file system and the storage
|
||||
it resides on. As last step the system is powered down.</para>
|
||||
it resides on. As a last step, the system is powered down.</para>
|
||||
|
||||
<para>Additional information about the system boot
|
||||
process may be found in
|
||||
@ -90,7 +91,7 @@
|
||||
systems, services and drivers that are necessary for
|
||||
operation of the system. On
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
systems this process is split up in various discrete
|
||||
systems, this process is split up in various discrete
|
||||
steps which are exposed as target units. (See
|
||||
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for detailed information about target units.) The
|
||||
@ -99,17 +100,17 @@
|
||||
deterministic, but still adheres to a limited amount
|
||||
of ordering structure.</para>
|
||||
|
||||
<para>When systemd starts up the system it will
|
||||
<para>When systemd starts up the system, it will
|
||||
activate all units that are dependencies of
|
||||
<filename>default.target</filename> (as well as
|
||||
recursively all dependencies of these
|
||||
dependencies). Usually
|
||||
dependencies). Usually,
|
||||
<filename>default.target</filename> is simply an alias
|
||||
of <filename>graphical.target</filename> or
|
||||
<filename>multi-user.target</filename> depending on
|
||||
<filename>multi-user.target</filename>, depending on
|
||||
whether the system is configured for a graphical UI or
|
||||
only for a text console. To enforce minimal ordering
|
||||
between the units pulled in a number of well-known
|
||||
between the units pulled in, a number of well-known
|
||||
target units are available, as listed on
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
|
||||
|
||||
@ -178,7 +179,7 @@
|
||||
<refsect1>
|
||||
<title>Bootup in the Initial RAM Disk (initrd)</title>
|
||||
<para>The initial RAM disk implementation (initrd) can
|
||||
be set up using systemd as well. In this case boot up
|
||||
be set up using systemd as well. In this case, boot up
|
||||
inside the initrd follows the following
|
||||
structure.</para>
|
||||
|
||||
|
||||
@ -83,15 +83,15 @@
|
||||
underlying block device, or a specification of a block
|
||||
device via <literal>UUID=</literal> followed by the
|
||||
UUID. If the block device contains a LUKS signature,
|
||||
it is opened as a LUKS encrypted partition; otherwise
|
||||
it is opened as a LUKS encrypted partition; otherwise,
|
||||
it is assumed to be a raw dm-crypt partition.</para>
|
||||
|
||||
<para>The third field specifies the encryption
|
||||
password. If the field is not present or the password
|
||||
is set to none, the password has to be manually
|
||||
entered during system boot. Otherwise the field is
|
||||
entered during system boot. Otherwise, the field is
|
||||
interpreted as a path to a file containing the
|
||||
encryption password. For swap encryption
|
||||
encryption password. For swap encryption,
|
||||
<filename>/dev/urandom</filename> or the hardware
|
||||
device <filename>/dev/hw_random</filename> can be used
|
||||
as the password file; using
|
||||
@ -239,7 +239,7 @@
|
||||
<listitem><para>The system will not
|
||||
wait for the device to show up and be
|
||||
unlocked at boot, and not fail the
|
||||
boot if it doesn't show
|
||||
boot if it does not show
|
||||
up.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -282,7 +282,7 @@
|
||||
</variablelist>
|
||||
|
||||
<para>At early boot and when the system manager
|
||||
configuration is reloaded this file is translated into
|
||||
configuration is reloaded, this file is translated into
|
||||
native systemd units
|
||||
by <citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</refsect1>
|
||||
|
||||
130
man/daemon.xml
130
man/daemon.xml
@ -79,7 +79,7 @@
|
||||
descriptors 0, 1, 2). This ensures
|
||||
that no accidentally passed file
|
||||
descriptor stays around in the daemon
|
||||
process. On Linux this is best
|
||||
process. On Linux, this is best
|
||||
implemented by iterating through
|
||||
<filename>/proc/self/fd</filename>,
|
||||
with a fallback of iterating from file
|
||||
@ -115,7 +115,7 @@
|
||||
|
||||
<listitem><para>In the child, call
|
||||
<function>fork()</function> again, to
|
||||
ensure the daemon can never re-acquire
|
||||
ensure that the daemon can never re-acquire
|
||||
a terminal again.</para></listitem>
|
||||
|
||||
<listitem><para>Call <function>exit()</function> in the
|
||||
@ -150,15 +150,15 @@
|
||||
<function>getpid()</function>) to a
|
||||
PID file, for example
|
||||
<filename>/var/run/foobar.pid</filename>
|
||||
(for a hypothetical daemon "foobar"),
|
||||
(for a hypothetical daemon "foobar")
|
||||
to ensure that the daemon cannot be
|
||||
started more than once. This must be
|
||||
implemented in race-free fashion so
|
||||
that the PID file is only updated when
|
||||
at the same time it is verified that
|
||||
it is verified at the same time that
|
||||
the PID previously stored in the PID
|
||||
file no longer exists or belongs to a
|
||||
foreign process. Commonly some kind of
|
||||
foreign process. Commonly, some kind of
|
||||
file locking is employed to implement
|
||||
this logic.</para></listitem>
|
||||
|
||||
@ -167,7 +167,7 @@
|
||||
applicable.</para></listitem>
|
||||
|
||||
<listitem><para>From the daemon
|
||||
process notify the original process
|
||||
process, notify the original process
|
||||
started that initialization is
|
||||
complete. This can be implemented via
|
||||
an unnamed pipe or similar
|
||||
@ -197,7 +197,7 @@
|
||||
implement the scheme pointed out
|
||||
above. However, it is recommended to make this
|
||||
behavior optional and configurable via a
|
||||
command line argument, to ease debugging as
|
||||
command line argument to ease debugging as
|
||||
well as to simplify integration into systems
|
||||
using systemd.</para>
|
||||
</refsect2>
|
||||
@ -211,20 +211,20 @@
|
||||
runtime and simplifies their
|
||||
implementation.</para>
|
||||
|
||||
<para>For developing a new-style daemon none
|
||||
<para>For developing a new-style daemon, none
|
||||
of the initialization steps recommended for
|
||||
SysV daemons need to be implemented. New-style
|
||||
init systems such as systemd make all of them
|
||||
redundant. Moreover, since some of these steps
|
||||
interfere with process monitoring, file
|
||||
descriptor passing and other functionality of
|
||||
the init system it is recommended not to
|
||||
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
|
||||
clean process contexts: it is guaranteed that
|
||||
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
|
||||
@ -256,7 +256,7 @@
|
||||
scripts</ulink>.</para></listitem>
|
||||
|
||||
<listitem><para>If possible and
|
||||
applicable expose the daemon's control
|
||||
applicable, expose the daemon's control
|
||||
interface via the D-Bus IPC system and
|
||||
grab a bus name as last step of
|
||||
initialization.</para></listitem>
|
||||
@ -274,7 +274,7 @@
|
||||
rely on the init system's
|
||||
functionality to limit the access of
|
||||
the daemon to files, services and
|
||||
other resources. i.e. in the case of
|
||||
other resources, i.e. in the case of
|
||||
systemd, rely on systemd's resource
|
||||
limit control instead of implementing
|
||||
your own, rely on systemd's privilege
|
||||
@ -285,7 +285,7 @@
|
||||
controls.</para></listitem>
|
||||
|
||||
<listitem><para>If D-Bus is used, make
|
||||
your daemon bus-activatable, via
|
||||
your daemon bus-activatable by
|
||||
supplying a D-Bus service activation
|
||||
configuration file. This has multiple
|
||||
advantages: your daemon may be started
|
||||
@ -293,7 +293,7 @@
|
||||
parallel to other daemons requiring it
|
||||
-- which maximizes parallelization and
|
||||
boot-up speed; your daemon can be
|
||||
restarted on failure, without losing
|
||||
restarted on failure without losing
|
||||
any bus requests, as the bus queues
|
||||
requests for activatable services. See
|
||||
below for details.</para></listitem>
|
||||
@ -304,17 +304,17 @@
|
||||
socket, it should be made
|
||||
socket-activatable following the
|
||||
scheme pointed out below. Like D-Bus
|
||||
activation this enables on-demand
|
||||
activation, this enables on-demand
|
||||
starting of services as well as it
|
||||
allows improved parallelization of
|
||||
service start-up. Also, for state-less
|
||||
protocols (such as syslog, DNS) a
|
||||
protocols (such as syslog, DNS), a
|
||||
daemon implementing socket-based
|
||||
activation can be restarted without
|
||||
losing a single request. See below for
|
||||
details.</para></listitem>
|
||||
|
||||
<listitem><para>If applicable a daemon
|
||||
<listitem><para>If applicable, a daemon
|
||||
should notify the init system about
|
||||
startup completion or status updates
|
||||
via the
|
||||
@ -327,7 +327,7 @@
|
||||
choose to simply log to STDERR via
|
||||
<function>fprintf()</function>, which is then forwarded to
|
||||
syslog by the init system. If log
|
||||
priorities are necessary these can be
|
||||
priorities are necessary, these can be
|
||||
encoded by prefixing individual log
|
||||
lines with strings like "<4>"
|
||||
(for log priority 4 "WARNING" in the
|
||||
@ -343,7 +343,7 @@
|
||||
kind of logging may be enabled by
|
||||
setting
|
||||
<varname>StandardError=syslog</varname>
|
||||
in the service unit file. For details
|
||||
in the service unit file. For details,
|
||||
see
|
||||
<citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
and
|
||||
@ -374,9 +374,9 @@
|
||||
when a printer is plugged in, or when a file is queued
|
||||
in the printer spool directory. Even for services that
|
||||
are intended to be started on system bootup
|
||||
unconditionally it is a good idea to implement some of
|
||||
unconditionally, it is a good idea to implement some of
|
||||
the various activation schemes outlined below, in
|
||||
order to maximize parallelization: if a daemon
|
||||
order to maximize parallelization. If a daemon
|
||||
implements a D-Bus service or listening socket,
|
||||
implementing the full bus and socket activation scheme
|
||||
allows starting of the daemon with its clients in
|
||||
@ -384,7 +384,7 @@
|
||||
communication channels are established already, and no
|
||||
request is lost because client requests will be queued
|
||||
by the bus system (in case of D-Bus) or the kernel (in
|
||||
case of sockets), until the activation is
|
||||
case of sockets) until the activation is
|
||||
completed.</para>
|
||||
|
||||
<refsect2>
|
||||
@ -399,7 +399,7 @@
|
||||
Specification</ulink>. This method of
|
||||
activation is supported ubiquitously on Linux
|
||||
init systems, both old-style and new-style
|
||||
systems. Among other issues SysV init scripts
|
||||
systems. Among other issues, SysV init scripts
|
||||
have the disadvantage of involving shell
|
||||
scripts in the boot process. New-style init
|
||||
systems generally employ updated versions of
|
||||
@ -409,7 +409,7 @@
|
||||
|
||||
<para>In systemd, if the developer or
|
||||
administrator wants to make sure a service or
|
||||
other unit is activated automatically on boot
|
||||
other unit is activated automatically on boot,
|
||||
it is recommended to place a symlink to the
|
||||
unit file in the <filename>.wants/</filename>
|
||||
directory of either
|
||||
@ -434,25 +434,25 @@
|
||||
recommended for all new-style daemons that
|
||||
communicate via listening sockets to employ
|
||||
socket-based activation. In a socket-based
|
||||
activation scheme the creation and binding of
|
||||
activation scheme, the creation and binding of
|
||||
the listening socket as primary communication
|
||||
channel of daemons to local (and sometimes
|
||||
remote) clients is moved out of the daemon
|
||||
code and into the init system. Based on
|
||||
per-daemon configuration the init system
|
||||
per-daemon configuration, the init system
|
||||
installs the sockets and then hands them off
|
||||
to the spawned process as soon as the
|
||||
respective daemon is to be started.
|
||||
Optionally activation of the service can be
|
||||
Optionally, activation of the service can be
|
||||
delayed until the first inbound traffic
|
||||
arrives at the socket, to implement on-demand
|
||||
arrives at the socket to implement on-demand
|
||||
activation of daemons. However, the primary
|
||||
advantage of this scheme is that all providers
|
||||
and all consumers of the sockets can be
|
||||
started in parallel as soon as all sockets
|
||||
are established. In addition to that daemons
|
||||
are established. In addition to that, daemons
|
||||
can be restarted with losing only a minimal
|
||||
number of client transactions or even any
|
||||
number of client transactions, or even any
|
||||
client request at all (the latter is
|
||||
particularly true for state-less protocols,
|
||||
such as DNS or syslog), because the socket
|
||||
@ -462,16 +462,16 @@
|
||||
|
||||
<para>New-style daemons which support socket
|
||||
activation must be able to receive their
|
||||
sockets from the init system, instead of
|
||||
sockets from the init system instead of
|
||||
creating and binding them themselves. For
|
||||
details about the programming interfaces for
|
||||
this scheme provided by systemd see
|
||||
this scheme provided by systemd, see
|
||||
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
and
|
||||
<citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>. For
|
||||
details about porting existing daemons to
|
||||
socket-based activation see below. With
|
||||
minimal effort it is possible to implement
|
||||
socket-based activation, see below. With
|
||||
minimal effort, it is possible to implement
|
||||
socket-based activation in addition to
|
||||
traditional internal socket creation in the
|
||||
same codebase in order to support both
|
||||
@ -483,20 +483,20 @@
|
||||
units, which are described in
|
||||
<citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>. When
|
||||
configuring socket units for socket-based
|
||||
activation it is essential that all listening
|
||||
activation, it is essential that all listening
|
||||
sockets are pulled in by the special target
|
||||
unit <filename>sockets.target</filename>. It
|
||||
is recommended to place a
|
||||
<varname>WantedBy=sockets.target</varname>
|
||||
directive in the <literal>[Install]</literal>
|
||||
section, to automatically add such a
|
||||
section to automatically add such a
|
||||
dependency on installation of a socket
|
||||
unit. Unless
|
||||
<varname>DefaultDependencies=no</varname> is
|
||||
set the necessary ordering dependencies are
|
||||
set, the necessary ordering dependencies are
|
||||
implicitly created for all socket units. For
|
||||
more information about
|
||||
<filename>sockets.target</filename> see
|
||||
<filename>sockets.target</filename>, see
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>. It
|
||||
is not necessary or recommended to place any
|
||||
additional dependencies on socket units (for
|
||||
@ -518,16 +518,16 @@
|
||||
service files (not to be confused with systemd
|
||||
service unit files!). To ensure that D-Bus
|
||||
uses systemd to start-up and maintain the
|
||||
daemon use the
|
||||
daemon, use the
|
||||
<varname>SystemdService=</varname> directive
|
||||
in these service files, to configure the
|
||||
in these service files to configure the
|
||||
matching systemd service for a D-Bus
|
||||
service. e.g.: for a D-Bus service whose D-Bus
|
||||
service. e.g.: For a D-Bus service whose D-Bus
|
||||
activation file is named
|
||||
<filename>org.freedesktop.RealtimeKit.service</filename>,
|
||||
make sure to set
|
||||
<varname>SystemdService=rtkit-daemon.service</varname>
|
||||
in that file, to bind it to the systemd
|
||||
in that file to bind it to the systemd
|
||||
service
|
||||
<filename>rtkit-daemon.service</filename>. This
|
||||
is needed to make sure that the daemon is
|
||||
@ -542,23 +542,23 @@
|
||||
type of hardware should be activated only when
|
||||
the hardware of the respective kind is plugged
|
||||
in or otherwise becomes available. In a
|
||||
new-style init system it is possible to bind
|
||||
new-style init system, it is possible to bind
|
||||
activation to hardware plug/unplug events. In
|
||||
systemd, kernel devices appearing in the
|
||||
sysfs/udev device tree can be exposed as units
|
||||
if they are tagged with the string
|
||||
<literal>systemd</literal>. Like any other
|
||||
kind of unit they may then pull in other units
|
||||
when activated (i.e. Plugged in) and thus
|
||||
implement device-based activation. Systemd
|
||||
kind of unit, they may then pull in other units
|
||||
when activated (i.e. plugged in) and thus
|
||||
implement device-based activation. systemd
|
||||
dependencies may be encoded in the udev
|
||||
database via the
|
||||
<varname>SYSTEMD_WANTS=</varname>
|
||||
property. See
|
||||
<citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for details. Often it is nicer to pull in
|
||||
for details. Often, it is nicer to pull in
|
||||
services from devices only indirectly via
|
||||
dedicated targets. Example: instead of pulling
|
||||
dedicated targets. Example: Instead of pulling
|
||||
in <filename>bluetoothd.service</filename>
|
||||
from all the various bluetooth dongles and
|
||||
other hardware available, pull in
|
||||
@ -610,10 +610,10 @@
|
||||
|
||||
<para>Other forms of activation have been
|
||||
suggested and implemented in some
|
||||
systems. However, often there are simpler or
|
||||
systems. However, there are often simpler or
|
||||
better alternatives, or they can be put
|
||||
together of combinations of the schemes
|
||||
above. Example: sometimes it appears useful to
|
||||
above. Example: Sometimes, it appears useful to
|
||||
start daemons or <filename>.socket</filename>
|
||||
units when a specific IP address is configured
|
||||
on a network interface, because network
|
||||
@ -634,7 +634,7 @@
|
||||
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
|
||||
features of the operating system, in
|
||||
particular, the CPU or IO scheduler of
|
||||
Linux. Instead of scheduling jobs from
|
||||
userspace based on monitoring the OS
|
||||
@ -668,7 +668,7 @@
|
||||
suggestions:</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem><para>If possible do not use
|
||||
<listitem><para>If possible, do not use
|
||||
the <varname>Type=forking</varname>
|
||||
setting in service files. But if you
|
||||
do, make sure to set the PID file path
|
||||
@ -711,15 +711,15 @@
|
||||
information for the unit file. See
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for details. To activate your service
|
||||
on boot make sure to add a
|
||||
on boot, make sure to add a
|
||||
<varname>WantedBy=multi-user.target</varname>
|
||||
or
|
||||
<varname>WantedBy=graphical.target</varname>
|
||||
directive. To activate your socket on
|
||||
boot, make sure to add
|
||||
<varname>WantedBy=sockets.target</varname>. Usually
|
||||
<varname>WantedBy=sockets.target</varname>. Usually,
|
||||
you also want to make sure that when
|
||||
your service is installed your socket
|
||||
your service is installed, your socket
|
||||
is installed too, hence add
|
||||
<varname>Also=foo.socket</varname> in
|
||||
your service file
|
||||
@ -735,7 +735,7 @@
|
||||
|
||||
<para>At the build installation time
|
||||
(e.g. <command>make install</command> during
|
||||
package build) packages are recommended to
|
||||
package build), packages are recommended to
|
||||
install their systemd unit files in the
|
||||
directory returned by <command>pkg-config
|
||||
systemd
|
||||
@ -748,12 +748,12 @@
|
||||
request but not activate them automatically
|
||||
during boot. Optionally, during package
|
||||
installation (e.g. <command>rpm -i</command>
|
||||
by the administrator) symlinks should be
|
||||
by the administrator), symlinks should be
|
||||
created in the systemd configuration
|
||||
directories via the <command>enable</command>
|
||||
command of the
|
||||
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
||||
tool, to activate them automatically on
|
||||
tool to activate them automatically on
|
||||
boot.</para>
|
||||
|
||||
<para>Packages using
|
||||
@ -801,7 +801,7 @@ endif</programlisting>
|
||||
|
||||
<para>In the
|
||||
<citerefentry><refentrytitle>rpm</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
||||
<filename>.spec</filename> file use snippets
|
||||
<filename>.spec</filename> file, use snippets
|
||||
like the following to enable/disable the
|
||||
service during
|
||||
installation/deinstallation. This makes use of
|
||||
@ -827,7 +827,7 @@ endif</programlisting>
|
||||
%systemd_postun</programlisting>
|
||||
|
||||
<para>If the service shall be restarted during
|
||||
upgrades replace the
|
||||
upgrades, replace the
|
||||
<literal>%postun</literal> scriptlet above
|
||||
with the following:</para>
|
||||
|
||||
@ -859,7 +859,7 @@ fi</programlisting>
|
||||
<para>Where 0.47.11-1 is the first package
|
||||
version that includes the native unit
|
||||
file. This fragment will ensure that the first
|
||||
time the unit file is installed it will be
|
||||
time the unit file is installed, it will be
|
||||
enabled if and only if the SysV init script is
|
||||
enabled, thus making sure that the enable
|
||||
status is not changed. Note that
|
||||
@ -875,13 +875,13 @@ fi</programlisting>
|
||||
<title>Porting Existing Daemons</title>
|
||||
|
||||
<para>Since new-style init systems such as systemd are
|
||||
compatible with traditional SysV init systems it is
|
||||
compatible with traditional SysV init systems, it is
|
||||
not strictly necessary to port existing daemons to the
|
||||
new style. However doing so offers additional
|
||||
new style. However, doing so offers additional
|
||||
functionality to the daemons as well as simplifying
|
||||
integration into new-style init systems.</para>
|
||||
|
||||
<para>To port an existing SysV compatible daemon the
|
||||
<para>To port an existing SysV compatible daemon, the
|
||||
following steps are recommended:</para>
|
||||
|
||||
<orderedlist>
|
||||
@ -896,7 +896,7 @@ fi</programlisting>
|
||||
interfaces to other software running on the
|
||||
local system via local <constant>AF_UNIX</constant> sockets,
|
||||
consider implementing socket-based activation
|
||||
(see above). Usually a minimal patch is
|
||||
(see above). Usually, a minimal patch is
|
||||
sufficient to implement this: Extend the
|
||||
socket creation in the daemon code so that
|
||||
<citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
||||
|
||||
@ -114,7 +114,7 @@
|
||||
<term><option>--force</option></term>
|
||||
|
||||
<listitem><para>Force immediate halt,
|
||||
power-off, reboot. Don't contact the
|
||||
power-off, reboot. Do not contact the
|
||||
init system.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -123,7 +123,7 @@
|
||||
<term><option>--wtmp-only</option></term>
|
||||
|
||||
<listitem><para>Only write wtmp
|
||||
shutdown entry, don't actually halt,
|
||||
shutdown entry, do not actually halt,
|
||||
power-off, reboot.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -131,14 +131,14 @@
|
||||
<term><option>-d</option></term>
|
||||
<term><option>--no-wtmp</option></term>
|
||||
|
||||
<listitem><para>Don't write wtmp
|
||||
<listitem><para>Do not write wtmp
|
||||
shutdown entry.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><option>--no-wall</option></term>
|
||||
|
||||
<listitem><para>Don't send wall
|
||||
<listitem><para>Do not send wall
|
||||
message before
|
||||
halt, power-off, reboot.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -56,7 +56,7 @@
|
||||
|
||||
<para>The <filename>/etc/hostname</filename> file
|
||||
configures the name of the local system that is set
|
||||
during boot, with the
|
||||
during boot using the
|
||||
<citerefentry><refentrytitle>sethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>
|
||||
system call. It should contain a single
|
||||
newline-terminated hostname string. The
|
||||
|
||||
@ -75,7 +75,7 @@
|
||||
<para>Note that the pretty hostname has little
|
||||
restrictions on the characters used, while the static
|
||||
and transient hostnames are limited to the usually
|
||||
accepted characters of internet domain names.</para>
|
||||
accepted characters of Internet domain names.</para>
|
||||
|
||||
<para>The static hostname is stored in
|
||||
<filename>/etc/hostname</filename>, see
|
||||
@ -110,7 +110,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--no-ask-password</option></term>
|
||||
|
||||
<listitem><para>Don't query the user
|
||||
<listitem><para>Do not query the user
|
||||
for authentication for privileged
|
||||
operations.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -64,11 +64,11 @@
|
||||
journal as written by
|
||||
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
|
||||
<para>If called without parameter it will show the full
|
||||
<para>If called without parameters, it will show the full
|
||||
contents of the journal, starting with the oldest
|
||||
entry collected.</para>
|
||||
|
||||
<para>If one or more match arguments are passed the
|
||||
<para>If one or more match arguments are passed, the
|
||||
output is filtered accordingly. A match is in the
|
||||
format <literal>FIELD=VALUE</literal>,
|
||||
e.g. <literal>_SYSTEMD_UNIT=httpd.service</literal>,
|
||||
@ -76,7 +76,7 @@
|
||||
entry. See
|
||||
<citerefentry><refentrytitle>systemd.journal-fields</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for a list of well-known fields. If multiple matches
|
||||
are specified matching different fields the log
|
||||
are specified matching different fields, the log
|
||||
entries are filtered by both, i.e. the resulting output
|
||||
will show only entries matching all the specified
|
||||
matches of this kind. If two matches apply to the same
|
||||
@ -85,25 +85,25 @@
|
||||
entries matching any of the specified matches for the
|
||||
same field. Finally, if the character
|
||||
<literal>+</literal> appears as separate word on the
|
||||
command line all matches before and after are combined
|
||||
command line, all matches before and after are combined
|
||||
in a disjunction (i.e. logical OR).</para>
|
||||
|
||||
<para>As shortcuts for a few types of field/value
|
||||
matches file paths may be specified. If a file path
|
||||
matches, file paths may be specified. If a file path
|
||||
refers to an executable file, this is equivalent to an
|
||||
<literal>_EXE=</literal> match for the canonicalized
|
||||
binary path. Similar, if a path refers to a device
|
||||
binary path. Similarly, if a path refers to a device
|
||||
node, this is equivalent to a
|
||||
<literal>_KERNEL_DEVICE=</literal> match for the
|
||||
device.</para>
|
||||
|
||||
<para>Output is interleaved from all accessible
|
||||
journal files, whether they are rotated or currently
|
||||
being written, and regardless whether they belong to the
|
||||
being written, and regardless of whether they belong to the
|
||||
system itself or are accessible user journals.</para>
|
||||
|
||||
<para>All users are granted access to their private
|
||||
per-user journals. However, by default only root and
|
||||
per-user journals. However, by default, only root and
|
||||
users who are members of the <literal>adm</literal>
|
||||
group get access to the system journal and the
|
||||
journals of other users.</para>
|
||||
@ -173,7 +173,7 @@
|
||||
the end of the journal inside the
|
||||
implied pager tool. This implies
|
||||
<option>-n1000</option> to guarantee
|
||||
that the pager won't buffer logs of
|
||||
that the pager will not buffer logs of
|
||||
unbounded size. This may be overridden
|
||||
with an explicit <option>-n</option>
|
||||
with some other numeric value on the
|
||||
@ -230,7 +230,7 @@
|
||||
<literal>cat</literal>. <literal>short</literal>
|
||||
is the default and generates an output
|
||||
that is mostly identical to the
|
||||
formatting of classic syslog log
|
||||
formatting of classic syslog
|
||||
files, showing one line per journal
|
||||
entry. <literal>short-monotonic</literal>
|
||||
is very similar but shows monotonic
|
||||
@ -285,7 +285,7 @@
|
||||
manuals. Note that help texts are not
|
||||
available for all messages, but only
|
||||
for selected ones. For more
|
||||
information on the message catalog
|
||||
information on the message catalog,
|
||||
please refer to the <ulink
|
||||
url="http://www.freedesktop.org/wiki/Software/systemd/catalog">Message
|
||||
Catalog Developer
|
||||
@ -386,10 +386,10 @@
|
||||
<literal>notice</literal> (5),
|
||||
<literal>info</literal> (6),
|
||||
<literal>debug</literal> (7). If a
|
||||
single log level is specified all
|
||||
single log level is specified, all
|
||||
messages with this log level or a
|
||||
lower (hence more important) log level
|
||||
are shown. If a range is specified all
|
||||
are shown. If a range is specified, all
|
||||
messages within the range are shown,
|
||||
including both the start and the end
|
||||
value of the range. This will add
|
||||
@ -468,7 +468,7 @@
|
||||
<term><option>--directory=<replaceable>DIR</replaceable></option></term>
|
||||
|
||||
<listitem><para>Takes a directory path
|
||||
as argument. If specified journalctl
|
||||
as argument. If specified, journalctl
|
||||
will operate on the specified journal
|
||||
directory
|
||||
<replaceable>DIR</replaceable> instead
|
||||
@ -480,7 +480,7 @@
|
||||
<term><option>--file=<replaceable>GLOB</replaceable></option></term>
|
||||
|
||||
<listitem><para>Takes a file glob as
|
||||
argument. If specified journalctl will
|
||||
argument. If specified, journalctl will
|
||||
operate on the specified journal files
|
||||
matching <replaceable>GLOB</replaceable>
|
||||
instead of the default runtime and
|
||||
@ -493,7 +493,7 @@
|
||||
<term><option>--root=<replaceable>ROOT</replaceable></option></term>
|
||||
|
||||
<listitem><para>Takes a directory path
|
||||
as argument. If specified journalctl
|
||||
as argument. If specified, journalctl
|
||||
will operate on catalog file hierarchy
|
||||
underneath the specified directory
|
||||
instead of the root directory
|
||||
@ -507,13 +507,13 @@
|
||||
<term><option>--new-id128</option></term>
|
||||
|
||||
<listitem><para>Instead of showing
|
||||
journal contents generate a new 128
|
||||
journal contents, generate a new 128
|
||||
bit ID suitable for identifying
|
||||
messages. This is intended for usage
|
||||
by developers who need a new
|
||||
identifier for a new message they
|
||||
introduce and want to make
|
||||
recognizable. Will print the new ID in
|
||||
recognizable. This will print the new ID in
|
||||
three different formats which can be
|
||||
copied into source code or
|
||||
similar.</para></listitem>
|
||||
@ -523,7 +523,7 @@
|
||||
<term><option>--header</option></term>
|
||||
|
||||
<listitem><para>Instead of showing
|
||||
journal contents show internal header
|
||||
journal contents, show internal header
|
||||
information of the journal fields
|
||||
accessed.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -587,7 +587,7 @@
|
||||
<term><option>--setup-keys</option></term>
|
||||
|
||||
<listitem><para>Instead of showing
|
||||
journal contents generate a new key
|
||||
journal contents, generate a new key
|
||||
pair for Forward Secure Sealing
|
||||
(FSS). This will generate a sealing
|
||||
key and a verification key. The
|
||||
@ -604,7 +604,7 @@
|
||||
<term><option>--interval=</option></term>
|
||||
|
||||
<listitem><para>Specifies the change
|
||||
interval for the sealing key, when
|
||||
interval for the sealing key when
|
||||
generating an FSS key pair with
|
||||
<option>--setup-keys</option>. Shorter
|
||||
intervals increase CPU consumption but
|
||||
@ -620,9 +620,9 @@
|
||||
<listitem><para>Check the journal file
|
||||
for internal consistency. If the
|
||||
file has been generated with FSS
|
||||
enabled, and the FSS verification key
|
||||
enabled and the FSS verification key
|
||||
has been specified with
|
||||
<option>--verify-key=</option>
|
||||
<option>--verify-key=</option>,
|
||||
authenticity of the journal file is
|
||||
verified.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -642,7 +642,7 @@
|
||||
<refsect1>
|
||||
<title>Exit status</title>
|
||||
|
||||
<para>On success 0 is returned, a non-zero failure
|
||||
<para>On success, 0 is returned, a non-zero failure
|
||||
code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -665,24 +665,24 @@
|
||||
<refsect1>
|
||||
<title>Examples</title>
|
||||
|
||||
<para>Without arguments all collected logs are shown
|
||||
<para>Without arguments, all collected logs are shown
|
||||
unfiltered:</para>
|
||||
|
||||
<programlisting>journalctl</programlisting>
|
||||
|
||||
<para>With one match specified all entries with a field matching the expression are shown:</para>
|
||||
<para>With one match specified, all entries with a field matching the expression are shown:</para>
|
||||
|
||||
<programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service</programlisting>
|
||||
|
||||
<para>If two different fields are matched only entries matching both expressions at the same time are shown:</para>
|
||||
<para>If two different fields are matched, only entries matching both expressions at the same time are shown:</para>
|
||||
|
||||
<programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097</programlisting>
|
||||
|
||||
<para>If two matches refer to the same field all entries matching either expression are shown:</para>
|
||||
<para>If two matches refer to the same field, all entries matching either expression are shown:</para>
|
||||
|
||||
<programlisting>journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service</programlisting>
|
||||
|
||||
<para>If the separator <literal>+</literal> is used
|
||||
<para>If the separator <literal>+</literal> is used,
|
||||
two expressions may be combined in a logical OR. The
|
||||
following will show all messages from the Avahi
|
||||
service process with the PID 28097 plus all messages
|
||||
|
||||
@ -54,8 +54,8 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This files configures various parameters of the
|
||||
systemd journal service
|
||||
<para>This file configures various parameters of the
|
||||
systemd journal service,
|
||||
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
|
||||
</refsect1>
|
||||
@ -77,13 +77,13 @@
|
||||
<literal>persistent</literal>,
|
||||
<literal>auto</literal> and
|
||||
<literal>none</literal>. If
|
||||
<literal>volatile</literal> journal
|
||||
<literal>volatile</literal>, journal
|
||||
log data will be stored only in
|
||||
memory, i.e. below the
|
||||
<filename>/run/log/journal</filename>
|
||||
hierarchy (which is created if
|
||||
needed). If
|
||||
<literal>persistent</literal> data will
|
||||
<literal>persistent</literal>, data will
|
||||
be stored preferably on disk,
|
||||
i.e. below the
|
||||
<filename>/var/log/journal</filename>
|
||||
@ -112,7 +112,7 @@
|
||||
<term><varname>Compress=</varname></term>
|
||||
|
||||
<listitem><para>Takes a boolean
|
||||
value. If enabled (the default) data
|
||||
value. If enabled (the default), data
|
||||
objects that shall be stored in the
|
||||
journal and are larger than a certain
|
||||
threshold are compressed with the XZ
|
||||
@ -125,7 +125,7 @@
|
||||
<term><varname>Seal=</varname></term>
|
||||
|
||||
<listitem><para>Takes a boolean
|
||||
value. If enabled (the default) and a
|
||||
value. If enabled (the default), and a
|
||||
sealing key is available (as created
|
||||
by
|
||||
<citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
||||
@ -149,23 +149,23 @@
|
||||
of <literal>login</literal>,
|
||||
<literal>uid</literal> and
|
||||
<literal>none</literal>. If
|
||||
<literal>login</literal> each logged
|
||||
in user will get his own journal
|
||||
<literal>login</literal>, each logged-in
|
||||
user will get his own journal
|
||||
files, but systemd user IDs will log
|
||||
into the system journal. If
|
||||
<literal>uid</literal> any user ID
|
||||
<literal>uid</literal>, any user ID
|
||||
will get his own journal files
|
||||
regardless whether it belongs to a
|
||||
system service or refers to a real
|
||||
logged in user. If
|
||||
<literal>none</literal> journal files
|
||||
are not split up per-user and all
|
||||
messages are stored in the single
|
||||
<literal>none</literal>, journal files
|
||||
are not split up by user and all
|
||||
messages are instead stored in the single
|
||||
system journal. Note that splitting
|
||||
up journal files per-user is only
|
||||
available of journals are stored
|
||||
up journal files by user is only
|
||||
available for journals stored
|
||||
persistently. If journals are stored
|
||||
on volatile storage (see above) only a
|
||||
on volatile storage (see above), only a
|
||||
single journal file for all user IDs
|
||||
is kept. Defaults to
|
||||
<literal>login</literal>.</para></listitem>
|
||||
@ -177,14 +177,14 @@
|
||||
|
||||
<listitem><para>Configures the rate
|
||||
limiting that is applied to all
|
||||
messages generated on the system. If
|
||||
messages generated on the system. If,
|
||||
in the time interval defined by
|
||||
<varname>RateLimitInterval=</varname>
|
||||
<varname>RateLimitInterval=</varname>,
|
||||
more messages than specified in
|
||||
<varname>RateLimitBurst=</varname> are
|
||||
logged by a service all further
|
||||
logged by a service, all further
|
||||
messages within the interval are
|
||||
dropped, until the interval is over. A
|
||||
dropped until the interval is over. A
|
||||
message about the number of dropped
|
||||
messages is generated. This rate
|
||||
limiting is applied per-service, so
|
||||
@ -227,13 +227,13 @@
|
||||
<filename>/run/log/journal</filename>. The
|
||||
former is used only when
|
||||
<filename>/var</filename> is mounted,
|
||||
writable and the directory
|
||||
writable, and the directory
|
||||
<filename>/var/log/journal</filename>
|
||||
exists. Otherwise only the latter
|
||||
exists. Otherwise, only the latter
|
||||
applies. Note that this means that
|
||||
during early boot and if the
|
||||
administrator disabled persistent
|
||||
logging only the latter options apply,
|
||||
logging, only the latter options apply,
|
||||
while the former apply if persistent
|
||||
logging is enabled and the system is
|
||||
fully booted
|
||||
@ -293,23 +293,26 @@
|
||||
|
||||
<listitem><para>The maximum time to
|
||||
store entries in a single journal
|
||||
file, before rotating to the next
|
||||
one. Normally time-based rotation
|
||||
file before rotating to the next
|
||||
one. Normally, time-based rotation
|
||||
should not be required as size-based
|
||||
rotation with options such as
|
||||
<varname>SystemMaxFileSize=</varname>
|
||||
should be sufficient to ensure that
|
||||
journal files don't grow without
|
||||
journal files do not grow without
|
||||
bounds. However, to ensure that not
|
||||
too much data is lost at once when old
|
||||
journal files are deleted it might
|
||||
journal files are deleted, it might
|
||||
make sense to change this value from
|
||||
the default of one month. Set to 0 to
|
||||
turn off this feature. This setting
|
||||
takes time values which may be
|
||||
suffixed with the units year, month,
|
||||
week, day, h, m to override the
|
||||
default time unit of
|
||||
suffixed with the units
|
||||
<literal>year</literal>,
|
||||
<literal>month</literal>,
|
||||
<literal>week</literal>, <literal>day</literal>,
|
||||
<literal>h</literal> or <literal>m</literal>
|
||||
to override the default time unit of
|
||||
seconds.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -321,31 +324,34 @@
|
||||
controls whether journal files
|
||||
containing entries older then the
|
||||
specified time span are
|
||||
deleted. Normally time-based deletion
|
||||
deleted. Normally, time-based deletion
|
||||
of old journal files should not be
|
||||
required as size-based deletion with
|
||||
options such as
|
||||
<varname>SystemMaxUse=</varname>
|
||||
should be sufficient to ensure that
|
||||
journal files don't grow without
|
||||
journal files do not grow without
|
||||
bounds. However, to enforce data
|
||||
retention policies it might make sense
|
||||
retention policies, it might make sense
|
||||
to change this value from the
|
||||
default of 0 (which turns off this
|
||||
feature). This setting also takes
|
||||
time values which may be suffixed with
|
||||
the units year, month, week, day, h, m
|
||||
the units <literal>year</literal>,
|
||||
<literal>month</literal>,
|
||||
<literal>week</literal>, <literal>day</literal>,
|
||||
<literal>h</literal> or <literal> m</literal>
|
||||
to override the default time unit of
|
||||
seconds. </para></listitem>
|
||||
seconds.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
||||
<varlistentry>
|
||||
<term><varname>SyncIntervalSec=</varname></term>
|
||||
|
||||
<listitem><para>The timeout before syncing journal
|
||||
data to disk. After syncing journal files have
|
||||
OFFLINE state. Default timeout is 5 minutes.
|
||||
<listitem><para>The timeout before synchronizing journal
|
||||
data to disk. After syncing, journal files have
|
||||
the OFFLINE state. Default timeout is 5 minutes.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -362,8 +368,8 @@
|
||||
system console. These options take
|
||||
boolean arguments. If forwarding to
|
||||
syslog is enabled but no syslog daemon
|
||||
is running the respective option has
|
||||
no effect. By default only forwarding
|
||||
is running, the respective option has
|
||||
no effect. By default, only forwarding
|
||||
to syslog is enabled. These settings
|
||||
may be overridden at boot time with
|
||||
the kernel command line options
|
||||
|
||||
@ -59,7 +59,7 @@
|
||||
kernel command line arguments.</para>
|
||||
|
||||
<para>For command line parameters understood by the
|
||||
kernel please see <ulink
|
||||
kernel, please see <ulink
|
||||
url="https://www.kernel.org/doc/Documentation/kernel-parameters.txt"><filename>kernel-parameters.txt</filename></ulink>
|
||||
and
|
||||
<citerefentry><refentrytitle>bootparam</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
|
||||
@ -93,7 +93,7 @@
|
||||
<listitem>
|
||||
<para>Parameters understood by
|
||||
the system and service manager
|
||||
to control system behavior. For details see
|
||||
to control system behavior. For details, see
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -105,7 +105,7 @@
|
||||
both the kernel and the system
|
||||
and service manager to control
|
||||
console log verbosity. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -117,7 +117,7 @@
|
||||
both the kernel and the system
|
||||
and service manager to control
|
||||
console log verbosity. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -136,7 +136,7 @@
|
||||
<para>Parameters understood by
|
||||
the system and service
|
||||
manager, as compatibility
|
||||
options. For details see
|
||||
options. For details, see
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -160,7 +160,7 @@
|
||||
<para>Parameters understood by
|
||||
the system and service manager
|
||||
to control locale and language
|
||||
settings. For details see
|
||||
settings. For details, see
|
||||
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -171,7 +171,7 @@
|
||||
<listitem>
|
||||
<para>Parameter understood by
|
||||
the file system checker
|
||||
services. For details see
|
||||
services. For details, see
|
||||
<citerefentry><refentrytitle>systemd-fsck@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -182,7 +182,7 @@
|
||||
<listitem>
|
||||
<para>Parameter understood by
|
||||
the file quota checker
|
||||
service. For details see
|
||||
service. For details, see
|
||||
<citerefentry><refentrytitle>systemd-quotacheck.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -195,7 +195,7 @@
|
||||
<listitem>
|
||||
<para>Parameters understood by
|
||||
the journal service. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>systemd-journald.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -210,7 +210,7 @@
|
||||
<listitem>
|
||||
<para>Parameters understood by
|
||||
the virtual console setup logic. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>systemd-vconsole-setup.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -227,7 +227,7 @@
|
||||
<listitem>
|
||||
<para>Parameters understood by
|
||||
the device event managing daemon. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>systemd-udevd.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -238,7 +238,7 @@
|
||||
<listitem>
|
||||
<para>May be used to disable
|
||||
the Plymouth boot splash. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>plymouth</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -256,7 +256,7 @@
|
||||
<listitem>
|
||||
<para>Configures the LUKS
|
||||
full-disk encryption logic at
|
||||
boot. For details see
|
||||
boot. For details, see
|
||||
<citerefentry><refentrytitle>systemd-cryptsetup-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -268,7 +268,7 @@
|
||||
<listitem>
|
||||
<para>Configures the
|
||||
<filename>/etc/fstab</filename>
|
||||
logic at boot. For details see
|
||||
logic at boot. For details, see
|
||||
<citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -280,7 +280,7 @@
|
||||
<listitem>
|
||||
<para>Load a specific kernel
|
||||
module early at boot. For
|
||||
details see
|
||||
details, see
|
||||
<citerefentry><refentrytitle>systemd-modules-load.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -73,7 +73,7 @@ along with systemd; If not, see <http://www.gnu.org/licenses/>.
|
||||
executables with a local file if needed; a symbolic link in <filename>/etc/kernel/install.d/</filename>
|
||||
with the same name as an executable in <filename>/usr/lib/kernel/install.d/</filename>,
|
||||
pointing to /dev/null, disables the executable entirely. Executables must have the
|
||||
extension .install; other extensions are ignored.</para>
|
||||
extension <literal>.install</literal>; other extensions are ignored.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
@ -112,7 +112,7 @@ add <replaceable>KERNEL-VERSION</replaceable> <filename>/boot/<replaceable>MACHI
|
||||
<varlistentry>
|
||||
<term><command>remove <replaceable>KERNEL-VERSION</replaceable></command></term>
|
||||
<listitem>
|
||||
<para>calls every executable <filename>/usr/lib/kernel/install.d/*.install</filename>
|
||||
<para>Calls every executable <filename>/usr/lib/kernel/install.d/*.install</filename>
|
||||
and <filename>/etc/kernel/install.d/*.install</filename> with the arguments
|
||||
<programlisting>
|
||||
remove <replaceable>KERNEL-VERSION</replaceable> <filename>/boot/<replaceable>MACHINE-ID</replaceable>/<replaceable>KERNEL-VERSION</replaceable>/</filename>
|
||||
@ -145,7 +145,7 @@ remove <replaceable>KERNEL-VERSION</replaceable> <filename>/boot/<replaceable>MA
|
||||
<filename>/etc/kernel/install.d/*.install</filename>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>Drop-in files, which are executed by kernel-install.</para>
|
||||
<para>Drop-in files which are executed by kernel-install.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
||||
@ -64,7 +64,7 @@
|
||||
newline-separated list of environment-like
|
||||
shell-compatible variable assignments. It is possible
|
||||
to source the configuration from shell scripts,
|
||||
however, beyond mere variable assignments no shell
|
||||
however, beyond mere variable assignments, no shell
|
||||
features are supported, allowing applications to read
|
||||
the file without implementing a shell compatible
|
||||
execution engine.</para>
|
||||
@ -92,7 +92,7 @@
|
||||
overridden or unset by individual programs or
|
||||
individual users.</para>
|
||||
|
||||
<para>Depending on the operating system other
|
||||
<para>Depending on the operating system, other
|
||||
configuration files might be checked for locale
|
||||
configuration as well, however only as
|
||||
fallback.</para>
|
||||
@ -132,7 +132,7 @@
|
||||
<para><filename>/etc/locale.conf</filename>:</para>
|
||||
|
||||
<programlisting>LANG=de_DE.UTF-8
|
||||
LC_MESSAGES=C</programlisting>
|
||||
LC_MESSAGES=en_US.UTF-8</programlisting>
|
||||
</example>
|
||||
|
||||
</refsect1>
|
||||
|
||||
@ -105,7 +105,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--no-ask-password</option></term>
|
||||
|
||||
<listitem><para>Don't query the user
|
||||
<listitem><para>Do not query the user
|
||||
for authentication for privileged
|
||||
operations.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -188,7 +188,7 @@
|
||||
one to define a toggle keyboard
|
||||
mapping. Unless
|
||||
<option>--no-convert</option> is
|
||||
passed the selected setting is also
|
||||
passed, the selected setting is also
|
||||
applied to the default keyboard
|
||||
mapping of X11, after converting it to
|
||||
the closest matching X11 keyboard
|
||||
@ -218,7 +218,7 @@
|
||||
<citerefentry><refentrytitle>kbd</refentrytitle><manvolnum>4</manvolnum></citerefentry>
|
||||
for details. Unless
|
||||
<option>--no-convert</option> is
|
||||
passed the selected setting is also
|
||||
passed, the selected setting is also
|
||||
applied to the system console keyboard
|
||||
mapping, after converting it to the
|
||||
closest matching console keyboard
|
||||
@ -249,7 +249,7 @@
|
||||
<refsect1>
|
||||
<title>Exit status</title>
|
||||
|
||||
<para>On success 0 is returned, a non-zero failure
|
||||
<para>On success, 0 is returned, a non-zero failure
|
||||
code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -74,9 +74,9 @@
|
||||
<citerefentry><refentrytitle>tzfile</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
timezone data for the configured timezone.</para>
|
||||
|
||||
<para>As the timezone identifier is extracted from
|
||||
<para>Because the timezone identifier is extracted from
|
||||
the symlink target name of
|
||||
<filename>/etc/localtime</filename> this file may not
|
||||
<filename>/etc/localtime</filename>, this file may not
|
||||
be a normal file or hardlink.</para>
|
||||
|
||||
<para>The timezone may be overridden for individual
|
||||
|
||||
@ -91,11 +91,11 @@
|
||||
session/user properties, limit
|
||||
display to certain properties as
|
||||
specified as argument. If not
|
||||
specified all set properties are
|
||||
specified, all set properties are
|
||||
shown. The argument should be a
|
||||
property name, such as
|
||||
<literal>Sessions</literal>. If
|
||||
specified more than once all
|
||||
specified more than once, all
|
||||
properties with the specified names
|
||||
are shown.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -129,7 +129,7 @@
|
||||
<varlistentry>
|
||||
<term><option>--no-ask-password</option></term>
|
||||
|
||||
<listitem><para>Don't query the user
|
||||
<listitem><para>Do not query the user
|
||||
for authentication for privileged
|
||||
operations.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -161,7 +161,7 @@
|
||||
<constant>SIGTERM</constant>,
|
||||
<constant>SIGINT</constant> or
|
||||
<constant>SIGSTOP</constant>. If
|
||||
omitted defaults to
|
||||
omitted, defaults to
|
||||
<constant>SIGTERM</constant>.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
@ -214,14 +214,14 @@
|
||||
|
||||
<listitem><para>Show properties of one
|
||||
or more sessions or the manager
|
||||
itself. If no argument is specified
|
||||
itself. If no argument is specified,
|
||||
properties of the manager will be
|
||||
shown. If a session ID is specified
|
||||
shown. If a session ID is specified,
|
||||
properties of the session is shown. By
|
||||
default, empty properties are
|
||||
suppressed. Use <option>--all</option>
|
||||
to show those too. To select specific
|
||||
properties to show use
|
||||
properties to show, use
|
||||
<option>--property=</option>. This
|
||||
command is intended to be used
|
||||
whenever computer-parsable output is
|
||||
@ -317,7 +317,7 @@
|
||||
default, empty properties are
|
||||
suppressed. Use <option>--all</option>
|
||||
to show those too. To select specific
|
||||
properties to show use
|
||||
properties to show, use
|
||||
<option>--property=</option>. This
|
||||
command is intended to be used
|
||||
whenever computer-parsable output is
|
||||
@ -337,7 +337,7 @@
|
||||
enabled for a specific user, a user
|
||||
manager is spawned for him/her at
|
||||
boot and kept around after
|
||||
logouts. This allows users who aren't
|
||||
logouts. This allows users who are not
|
||||
logged in to run long-running
|
||||
services.</para></listitem>
|
||||
</varlistentry>
|
||||
@ -455,7 +455,7 @@
|
||||
<refsect1>
|
||||
<title>Exit status</title>
|
||||
|
||||
<para>On success 0 is returned, a non-zero failure
|
||||
<para>On success, 0 is returned, a non-zero failure
|
||||
code otherwise.</para>
|
||||
</refsect1>
|
||||
|
||||
|
||||
@ -54,7 +54,7 @@
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This file configures various parameters of the systemd login manager <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
<para>This file configures various parameters of the systemd login manager, <citerefentry><refentrytitle>systemd-logind.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
@ -81,7 +81,7 @@
|
||||
<filename>autovt@.service</filename>
|
||||
for the respective VT TTY name,
|
||||
e.g. <filename>autovt@tty4.service</filename>. By
|
||||
default
|
||||
default,
|
||||
<filename>autovt@.service</filename>
|
||||
is linked to
|
||||
<filename>getty@.service</filename>,
|
||||
@ -92,7 +92,7 @@
|
||||
<literal>gettys</literal> are
|
||||
available on the VTs. If a VT is
|
||||
already used by some other subsystem
|
||||
(for example a graphical login) this
|
||||
(for example a graphical login), this
|
||||
kind of activation will not be
|
||||
attempted. Note that the VT configured
|
||||
in <varname>ReserveVT=</varname> is
|
||||
@ -103,7 +103,7 @@
|
||||
directive. Defaults to 6. When set to
|
||||
0, automatic spawning of
|
||||
<literal>autovt</literal> services is
|
||||
disabled. </para></listitem>
|
||||
disabled.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
@ -120,10 +120,10 @@
|
||||
other subsystem will allocate it. This
|
||||
functionality is useful to ensure that
|
||||
regardless how many VTs are allocated
|
||||
by other subsystems one login
|
||||
by other subsystems, one login
|
||||
<literal>getty</literal> is always
|
||||
available. Defaults to 6 (with other
|
||||
words: there'll always be a
|
||||
words: there will always be a
|
||||
<literal>getty</literal> available on
|
||||
Alt-F6.). When set to 0, VT
|
||||
reservation is
|
||||
@ -304,7 +304,7 @@
|
||||
<literal>off</literal>, the inhibitor
|
||||
locks taken by applications in order
|
||||
to block the requested operation are
|
||||
respected, if <literal>on</literal>,
|
||||
respected. If <literal>on</literal>,
|
||||
the requested operation is executed in
|
||||
any
|
||||
case. <varname>PowerKeyIgnoreInhibited=</varname>,
|
||||
@ -330,7 +330,7 @@
|
||||
|
||||
<para>Note that <varname>KillUserProcesses=1</varname>
|
||||
is a weaker version of
|
||||
<varname>kill-session-processes=1</varname> which may
|
||||
<varname>kill-session-processes=1</varname>, which may
|
||||
be configured per-service for
|
||||
<citerefentry><refentrytitle>pam_systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>. The
|
||||
latter kills processes of a session as soon as it
|
||||
|
||||
@ -65,7 +65,7 @@
|
||||
<para>The machine ID is usually generated from a
|
||||
random source during system installation and stays
|
||||
constant for all subsequent boots. Optionally, for
|
||||
stateless systems it is generated during runtime at
|
||||
stateless systems, it is generated during runtime at
|
||||
boot if it is found to be empty.</para>
|
||||
|
||||
<para>The machine ID does not change based on user
|
||||
@ -113,7 +113,7 @@ id[8] = (id[8] & 0x3F) | 0x80;</programlisting>
|
||||
<para>(This code is inspired by
|
||||
<literal>generate_random_uuid()</literal> of
|
||||
<filename>drivers/char/random.c</filename> from the
|
||||
kernel sources.)</para>
|
||||
Linux kernel sources.)</para>
|
||||
|
||||
</refsect1>
|
||||
|
||||
@ -123,7 +123,7 @@ id[8] = (id[8] & 0x3F) | 0x80;</programlisting>
|
||||
<para>The simple configuration file format of
|
||||
<filename>/etc/machine-id</filename> originates in the
|
||||
<filename>/var/lib/dbus/machine-id</filename> file
|
||||
introduced by D-Bus. In fact this latter file might be a
|
||||
introduced by D-Bus. In fact, this latter file might be a
|
||||
symlink to
|
||||
<varname>/etc/machine-id</varname>.</para>
|
||||
</refsect1>
|
||||
|
||||
@ -797,7 +797,7 @@
|
||||
highly recommended to leave this
|
||||
option enabled for the majority of
|
||||
common units. If set to
|
||||
<option>false</option> this option
|
||||
<option>false</option>, this option
|
||||
does not disable all implicit
|
||||
dependencies, just non-essential
|
||||
ones.</para></listitem>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user