Docs/quick-docs
1
0
Fork 0
Code Issues 48 Pull requests 1 Projects Releases Packages Wiki Activity Actions

uppercase Systemd at sentence beginning

Browse source
This commit is contained in:
Christopher Engelhard 2020-08-05 18:48:54 +02:00 • committed by lcts
parent 9ded02053a
commit ac8c154d2a
4 changed files with 5 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

4
modules/ROOT/pages/_partials/con_understanding-systemd.adoc
View file

@ -1,7 +1,7 @@
[id='understanding-systemd'] [id='understanding-systemd']
= Understanding systemd = Understanding systemd
_systemd_ is a system and service manager for Linux, compatible with SysV and LSB init scripts. _systemd_ provides: _Systemd_ is a system and service manager for Linux, compatible with SysV and LSB init scripts. _Systemd_ provides:
* Aggressive parallelization capabilities * Aggressive parallelization capabilities
* Uses socket and D-Bus activation for starting services * Uses socket and D-Bus activation for starting services
@ -12,7 +12,7 @@ _systemd_ is a system and service manager for Linux, compatible with SysV and LS
The `systemctl` command is the primary tool to manage _systemd_. It combines the functionality of SysVinit's `service` and `chkconfig` commands into a single tool you can use to enable and disable services permanently or only for the current session. The `systemctl` command is the primary tool to manage _systemd_. It combines the functionality of SysVinit's `service` and `chkconfig` commands into a single tool you can use to enable and disable services permanently or only for the current session.
_systemd_ manages so-called *_units_*, which are representations of system resources and services. This following list shows the unit types that _systemd_ can manage: _Systemd_ manages so-called *_units_*, which are representations of system resources and services. This following list shows the unit types that _systemd_ can manage:
service:: service::
A service on the system, including instructions for starting, restarting, and stopping the service. A service on the system, including instructions for starting, restarting, and stopping the service.

2
modules/ROOT/pages/_partials/proc_creating-new-systemd-services.adoc
View file

@ -24,7 +24,7 @@ This procedure creates a basic configuration file to control the `foo` service.
.. The `[Unit]` section provides basic information about the service. The `foo` service uses the following parameters: .. The `[Unit]` section provides basic information about the service. The `foo` service uses the following parameters:
+ +
`Description`:: `Description`::
A string describing the unit. _systemd_ displays this description next to the unit name in the user interface. A string describing the unit. _Systemd_ displays this description next to the unit name in the user interface.
`Requires`:: `Requires`::
Defines unit to use as a dependency for the service. If you activate the unit, _systemd_ activates the units listed in `Requires` as well. For example, the `foo` service might require network connectivity, which means the `foo` services requires `network.target` as a dependency. Defines unit to use as a dependency for the service. If you activate the unit, _systemd_ activates the units listed in `Requires` as well. For example, the `foo` service might require network connectivity, which means the `foo` services requires `network.target` as a dependency.
+ +

2
modules/ROOT/pages/_partials/ref_common-service-parameters.adoc
View file

@ -72,7 +72,7 @@ GuessMainPID::
A boolean value that specifies whether _systemd_ should guess the main PID of a service if it cannot be determined reliably. This option is ignored unless `Type=forking` is set and `PIDFile` is not set. Defaults to yes. A boolean value that specifies whether _systemd_ should guess the main PID of a service if it cannot be determined reliably. This option is ignored unless `Type=forking` is set and `PIDFile` is not set. Defaults to yes.
PIDFile:: PIDFile::
An absolute filename pointing to the PID file of this daemon. Use of this option is recommended for services where `Type=forking`. _systemd_ reads the PID of the main process of the daemon after start-up of the service. _systemd_ does not write to the file configured here, although it removes the file after the service has shut down. An absolute filename pointing to the PID file of this daemon. Use of this option is recommended for services where `Type=forking`. _Systemd_ reads the PID of the main process of the daemon after start-up of the service. _Systemd_ does not write to the file configured here, although it removes the file after the service has shut down.
BusName:: BusName::
A D-Bus bus name to reach this service. This option is mandatory for services where `Type=dbus`. A D-Bus bus name to reach this service. This option is mandatory for services where `Type=dbus`.

2
modules/ROOT/pages/_partials/ref_mapping-runlevel-to-targets.adoc
View file

@ -1,7 +1,7 @@
[#mapping-runlevels-to-targets] [#mapping-runlevels-to-targets]
= Mapping runlevels to targets = Mapping runlevels to targets
_systemd_ targets serve a similar purpose to SysVinit runlevels but act a little differently. Each target has a name instead of a number and each serves a specific purpose. _systemd_ implements some targets by inheriting all of the services of another target and adding additional services to it. Some _systemd_ targets mimic the common sysvinit runlevels, which means you can switch targets with the familiar `telinit RUNLEVEL` command. The runlevels assigned a specific purpose on vanilla Fedora installs (0, 1, 3, 5, and 6) have a 1:1 mapping with a specific _systemd_ target. _Systemd_ targets serve a similar purpose to SysVinit runlevels but act a little differently. Each target has a name instead of a number and each serves a specific purpose. _Systemd_ implements some targets by inheriting all of the services of another target and adding additional services to it. Some _systemd_ targets mimic the common sysvinit runlevels, which means you can switch targets with the familiar `telinit RUNLEVEL` command. The runlevels assigned a specific purpose on vanilla Fedora installs (0, 1, 3, 5, and 6) have a 1:1 mapping with a specific _systemd_ target.
However, this is not the case for user-defined runlevels 2 and 4. To make use of those runlevels, create a new named _systemd_ target such as `/etc/systemd/system/$YOURTARGET` that takes one of the existing runlevels as a base, make a directory `/etc/systemd/system/$YOURTARGET.wants`, and then symlink the additional services to enable into that directory. However, this is not the case for user-defined runlevels 2 and 4. To make use of those runlevels, create a new named _systemd_ target such as `/etc/systemd/system/$YOURTARGET` that takes one of the existing runlevels as a base, make a directory `/etc/systemd/system/$YOURTARGET.wants`, and then symlink the additional services to enable into that directory.