PR#259: Reviewed/updated "Understanding and administering systemd" - fedora-docs/quick-docs

		`@@ -1,7 +1,7 @@`
		`[id='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`
		`* Uses socket and D-Bus activation for starting services`
		`@@ -10,9 +10,9 @@`
		`* Maintains mount and automount points`
		`* Implements an elaborate transactional dependency-based service control logic.`

		- 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 _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::`
		`A service on the system, including instructions for starting, restarting, and stopping the service.`
		`@@ -21,10 +21,10 @@`
		`A network socket associated with a service.`

		`device::`
		`- A device specifically managed with systemd.`
		`+ A device specifically managed with _systemd_.`

		`mount::`
		`- A mountpoint managed with systemd.`
		`+ A mountpoint managed with _systemd_.`

		`automount::`
		`A mountpoint automatically mounted on boot.`
		`@@ -42,10 +42,10 @@`
		`A timer to schedule activation of another unit.`

		`snapshot::`
		`- A snapshot of the current systemd state. Usually used to rollback after making temporary changes to systemd.`
		`+ A snapshot of the current _systemd_ state. Usually used to rollback after making temporary changes to _systemd_.`

		`slice::`
		`Restriction of resources through Linux Control Group nodes (cgroups).`

		`scope::`
		`- Information from systemd bus interfaces. Usually used to manage external system processes.`
		`+ Information from _systemd_ bus interfaces. Usually used to manage external system processes.`

modules/ROOT/pages/_partials/proc_converting-sysvinit-services.adoc

file modified

+13 -10

		`@@ -1,15 +1,17 @@`
		`[#converting-sysvinit-services]`
		`- = Converting SysVinit services`
		`+ = Converting SysVinit services to systemd`

		`- Older versions of Fedora use SysVinit scripts to manage services. This section provides some guidelines on how to convert a SysVinit script to a systemd equivalent.`
		`+ Older versions of Fedora use SysVinit scripts to manage services. This section provides some guidelines on how to convert a SysVinit script to a _systemd_ equivalent.`

		`- .Prerequisites`
		`+ [discrete]`
		`+ == Prerequisites`

		`* You are logged in as a user with administrator-level permissions.`

		`- * You have a custom SysVinit script to convert to a systemd configuration.`
		`+ * You have a custom SysVinit script to convert to a _systemd_ configuration.`

		`- .Procedure`
		`+ [discrete]`
		`+ == Procedure`

		. Identify the runlevels in your SysVinit script. This is usually defined with `chkconfig` directive in the commented section at the beginning of the script. For example, the following indicates the service is using runlevels 3, 4, and 5:
		`+`
		`@@ -17,14 +19,14 @@`
		`# chkconfig: 235 20 80`
		`----`
		`+`
		`- systemd uses targets instead of runlevels. Use the table in <<#converting-sysvinit-services>> to map the runlevels to targets. In this example, runlevels 2, 3, and 5 are all multi-user runlevels, so the systemd service can use the following:`
		`+ systemd uses targets instead of runlevels. Use the table in <<#converting-sysvinit-services>> to map the runlevels to targets. In this example, runlevels 2, 3, and 5 are all multi-user runlevels, so the _systemd_ service can use the following:`
		`+`
		`----`
		`[Install]`
		`WantedBy=multi-user.target`
		`----`
		`+`
		- If you enable the custom systemd service to start at boot (`systemctl enable foo.service`), systemd loads the service when loading the `multi-user.target` at boot time.
		+ If you enable the custom _systemd_ service to start at boot (`systemctl enable foo.service`), _systemd_ loads the service when loading the `multi-user.target` at boot time.

		. Identify the dependent services and targets. For example, if the custom service requires network connectivity, specify the `network.target` as a dependency:
		`+`
		`@@ -34,7 +36,7 @@`
		`Requires=network.target`
		`----`

		- . Identify the command used to start the service in the SysVinit script and convert this to the systemd equivalent. For example, the script might contain a `start` function in the following format:
		+ . Identify the command used to start the service in the SysVinit script and convert this to the _systemd_ equivalent. For example, the script might contain a `start` function in the following format:
		`+`
		`[source,bash]`
		`----`
		`@@ -89,8 +91,9 @@`
		`+`
		Alternatively, you can omit `ExecStop` and use the default behavior, which kills the service.

		`- . Review the SysVinit script and identify any additional parameters or functions. Use systemd parameters to replicate any identified SysVinit functions that might be relevant to your service.`
		`+ . Review the SysVinit script and identify any additional parameters or functions. Use _systemd_ parameters to replicate any identified SysVinit functions that might be relevant to your service.`

		`- .Related Information`
		`+ [discrete]`
		`+ == Related Information`

		`* See link:#common-service-parameters[Common service parameters] for more information about the parameters used in this procedure.`

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

file modified

+19 -9

		`@@ -3,18 +3,20 @@`

		This example shows how to create a unit file for a custom service. Custom unit files are located in `/etc/systemd/system/` and have a `.service` extension. For example, a custom `foo` service uses `/etc/systemd/system/foo.service` unit file.

		`- .Prerequisites`
		`+ [discrete]`
		`+ == Prerequisites`

		`* You are logged in as a user with administrator-level permissions.`

		`- .Procedure`
		`+ [discrete]`
		`+ == Procedure`

		This procedure creates a basic configuration file to control the `foo` service.

		`. Create and edit the new configuration file:`
		`+`
		`----`
		`- # vi /etc/systemd/system/foo.service`
		`+ # nano /etc/systemd/system/foo.service`
		`----`

		`. The next few steps describe each section its parameters to add to the file:`
		`@@ -22,9 +24,9 @@`
		.. The `[Unit]` section provides basic information about the service. The `foo` service uses the following parameters:
		`+`
		`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`::
		- 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.
		`+`
		The resulting `[Unit]` section looks like this:
		`+`
		`@@ -37,7 +39,7 @@`
		.. The `[Service]` section provides instructions on how to control the service. The `foo` service uses the following parameters:
		`+`
		`Type`::
		- Defines the type of systemd service. In this example, the `foo` service is a `simple` service, which starts the service without any special consideration.
		+ Defines the type of _systemd_ service. In this example, the `foo` service is a `simple` service, which starts the service without any special consideration.
		`ExecStart`::
		`The command to run to start the service. This includes the full path to the command and arguments to modify the service.`
		`+`
		`@@ -49,10 +51,10 @@`
		`ExecStart=/usr/bin/sleep infinity`
		`----`

		- .. The `[Install]` section provides instructions on how systemd installs the service. The `foo` service uses the following parameters:
		+ .. The `[Install]` section provides instructions on how _systemd_ installs the service. The `foo` service uses the following parameters:
		`+`
		`WantedBy`::
		- Defines which service triggers the custom service if enabled with `systemctl enable`. This is mostly used for starting the custom service on boot. In this example, `foo.service` uses `multi-user.target`, which starts `foo.service` when systemd loads `multi-user.target` on boot.
		+ Defines which service triggers the custom service if enabled with `systemctl enable`. This is mostly used for starting the custom service on boot. In this example, `foo.service` uses `multi-user.target`, which starts `foo.service` when _systemd_ loads `multi-user.target` on boot.

		. The full `foo.service` file contains the following contents:
		`+`
		`@@ -71,6 +73,13 @@`
		`+`
		`Save the file.`

		`+ . To make _systemd_ aware of the new service, reload its service files`
		`+ +`
		`+ ----`
		`+ # systemctl daemon-reload`
		`+ ----`
		`+`
		`+`
		. Start the custom `foo` service:
		`+`
		`----`
		`@@ -92,6 +101,7 @@`
		`Dec 14 14:09:12 dansmachine systemd[1]: Started My custom service.`
		`----`

		`- .Related Information`
		`+ [discrete]`
		`+ == Related Information`

		`* See link:#common-service-parameters[Common service parameters] for more information about the parameters used in this procedure.`

modules/ROOT/pages/_partials/proc_modifying-existing-systemd-services.adoc

file modified

+22 -13

		`@@ -1,27 +1,25 @@`
		`[#modifying-existing-systemd-services]`
		`= Modifying existing systemd services`

		- This example shows how to modify an existing service. The files for service modification are stored in a directory within `/etc/systemd/system`. This directory is named after the service. For example, this procedure modifies the `httpd` service.
		+ This example shows how to modify an existing service. Service modification are stored within `/etc/systemd/system`, in a single file or in a subdirectory named after the service. For example, this procedure modifies the `httpd` service.

		`- .Prerequisites`
		`+ [discrete]`
		`+ == Prerequisites`

		`* You are logged in as a user with administrator-level permissions.`

		- * You have a configured `httpd` server running through systemd.
		+ * You have a configured `httpd` server running through _systemd_.

		`- .Procedure`
		`+ [discrete]`
		`+ == Procedure`

		- . Create a directory for the service modification in the following format: `[SERVICE NAME].service.d`. For example, the directory for the `httpd.service` modification is `httpd.service.d`:
		+ . _Systemd_ services can be modified using the `systemctl edit` command.
		`+`
		`----`
		`- # mkdir /etc/systemd/system/httpd.service.d/`
		`+ # systemctl edit httpd.service`
		`----`
		`-`
		`- . Create a configuration file within this directory:`
		`+`
		`- ----`
		`- # vi /etc/systemd/system/httpd.service.d/custom.conf`
		`- ----`
		+ This creates an override file `/etc/systemd/system/httpd.service.d/override.conf` and opens it in your text editor. Anything you put into this file will be added to the existing service file.

		`. Add your custom configuration. For example:`
		`+`
		`@@ -30,8 +28,16 @@`
		`Restart=always`
		`RestartSec=30`
		`----`
		`+ +`
		`+ To replace an option that can be set multiple times, it must cleared first, otherwise the override file will add the option a second time.`
		`+ +`
		`+ ----`
		`+ [Service]`
		`+ ExecStart=`
		`+ ExecStart=<new command>`
		`+ ----`

		`- . Save the file.`
		`+ . Save the file. _Systemd_ automatically loads the new service configuration.`

		. Restart the `httpd` service:
		`+`
		`@@ -39,6 +45,9 @@`
		`# systemctl restart httpd`
		`----`

		`- .Related Information`
		+ To completely replace (instead of just add to/modify) an existing service file, use `systemctl edit --full`, e.g. `systemctl edit --full httpd.service`. This will create `/etc/systemctl/system/httpd.service`, which will be used instead of the existing service file.
		`+`
		`+ [discrete]`
		`+ == Related Information`

		`* See link:#common-service-parameters[Common service parameters] for more information about the parameters used in this procedure.`

modules/ROOT/pages/_partials/proc_starting-stopping-and-querying-systemd-services.adoc

file modified

+11 -8

		`@@ -1,13 +1,15 @@`
		`[#starting-stopping-and-querying-systemd-services]`
		`= Starting, stopping, and querying systemd services`

		- You can perform various management tasks to control systemd services using the `systemctl` command. The following is a set of example commands to demonstrate how to use `systemctl` to manage systemd services.
		+ You can perform various management tasks to control _systemd_ services using the `systemctl` command. The following is a set of example commands to demonstrate how to use `systemctl` to manage _systemd_ services.

		`- .Prerequisites`
		`+ [discrete]`
		`+ == Prerequisites`

		`You are logged in as a user with administrator-level permissions.`

		`- .Procedure`
		`+ [discrete]`
		`+ == Procedure`

		The following commands control the `foo` service:

		`@@ -29,19 +31,19 @@`
		`# systemctl restart foo`
		`----`

		`- * Show the status of a service including if it is running or not:`
		`+ * Show the status of a service including, whether it is running or not:`
		`+`
		`----`
		`# systemctl status foo`
		`----`

		`- * Enable a service to be started on bootup:`
		`+ * Enable a service to be started on boot:`
		`+`
		`----`
		`# systemctl enable foo`
		`----`

		`- * Disable a service to not start during bootup:`
		`+ * Disable a service to not start during boot:`
		`+`
		`----`
		`# systemctl disable foo`
		`@@ -53,12 +55,13 @@`
		`# systemctl mask foo`
		`----`

		`- * Check if a service is already enabled or not:`
		`+ * Check if a service is enabled or not:`
		`+`
		`----`
		`# systemctl is-enabled foo`
		`----`

		`- .Related Information`
		`+ [discrete]`
		`+ == Related Information`

		* Run `man systemctl` for more details.

modules/ROOT/pages/_partials/ref_common-service-parameters.adoc

file modified

+10 -10

		`@@ -1,9 +1,9 @@`
		`[#common-service-parameters]`
		`= Common service parameters`

		`- .Unit Parameters`
		`+ == Unit Parameters`

		- This section contains parameters you can use in the `[Unit]` section of a service. These parameters are common to other systemd units.
		+ This section contains parameters you can use in the `[Unit]` section of a service. These parameters are common to other _systemd_ units.

		This list is a summarized version. For a full list of these parameters and their descriptions, run `man systemd.unit`.

		`@@ -14,7 +14,7 @@`
		A space-separated list of URIs referencing documentation for this service or its configuration. Accepted are only URIs of the following types: `http://`, `https://`, `file:`, `info:`, `man:`.

		`Requires::`
		`- Configures requirement dependencies on other services. If this service gets activated, the units listed here are activated too. If one of the dependent services fails to activate, systemd does not start this service. This option may be specified more than once or you can specify multiple space-separated units.`
		`+ Configures requirement dependencies on other services. If this service gets activated, the units listed here are activated too. If one of the dependent services fails to activate, _systemd_ does not start this service. This option may be specified more than once or you can specify multiple space-separated units.`

		`Wants::`
		Similar to `Requires`, except failed units do not have any effect on the service.
		`@@ -34,9 +34,9 @@`
		`OnFailure::`
		`A space-separated list of unit names that are activated when this service enters a failed state.`

		`- .Install Parameters`
		`+ == Install Parameters`

		- This section contains parameters you can use in the `[Install]` section of a service. These parameters are common to other systemd units.
		+ This section contains parameters you can use in the `[Install]` section of a service. These parameters are common to other _systemd_ units.

		This list is a summarized version. For a full list of these parameters and their descriptions, run `man systemd.unit`.

		`@@ -49,9 +49,9 @@`
		`Also::`
		`Additional units to install or uninstall when this service is installed or uninstalled.`

		`- .Service Parameters`
		`+ == Service Parameters`

		- This section contains parameters you can use in the `[Service]` section of a service unit. These parameters are specific only to systemd service units.
		+ This section contains parameters you can use in the `[Service]` section of a service unit. These parameters are specific only to _systemd_ service units.

		This list is a summarized version. For a full list of these parameters and their descriptions, run `man systemd.unit`.

		`@@ -60,7 +60,7 @@`
		`+`
		* `simple` - The service starts as the main process. This is the default.
		* `forking` - The service calls forked processes and run as part of the main daemon.
		- * `oneshot` - Similar to `simple`, except the process must exit before systemd starts follow-up services.
		+ * `oneshot` - Similar to `simple`, except the process must exit before _systemd_ starts follow-up services.
		* `dbus` - Similar to `simple`, except the daemon acquires a name of the D-Bus bus.
		* `notify` - Similar to `simple`, except the daemon sends a notification message using `sd_notify` or an equivalent call after starting up.
		* `idle` - Similar to `simple`, except the execution of the service is delayed until all active jobs are dispatched.
		`@@ -69,10 +69,10 @@`
		`A boolean value that specifies whether the service shall be considered active even if all its processes exited. Defaults to no.`

		`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::`
		- 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::`
		A D-Bus bus name to reach this service. This option is mandatory for services where `Type=dbus`.

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

file modified

+4 -4

		`@@ -1,11 +1,11 @@`
		`[#mapping-runlevels-to-targets]`
		`= Mapping runlevels to targets`

		- systemd targets serve a similar purpose to SysVinit runlevels but act a little different. 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.

		`- The following is a mapping of SysVinit runlevels to systemd targets.`
		`+ The following is a mapping of SysVinit runlevels to _systemd_ targets.`

		`[cols="2,5,5",options="header"]`
		`.Runlevel to target mapping`
		`@@ -28,4 +28,4 @@`
		`\|6 \|runlevel6.target, reboot.target \|Reboot`

		`\|emergency \|emergency.target \|Emergency shell`
		`- \|===`
		`\ No newline at end of file`
		`+ \|===`

modules/ROOT/pages/_partials/ref_mapping-service-commands.adoc

file modified

+4 -4

		`@@ -1,9 +1,9 @@`
		`[#mapping-service-commands]`
		`= Mapping service commands`

		`- The following table demonstrates the systemd equivalent of SysVinit commands.`
		`+ The following table demonstrates the _systemd_ equivalent of SysVinit commands.`

		- NOTE: All recent versions of systemctl assume the `.service` suffix if left off the service name. For example, `systemctl start frobozz.service` is the same as `systemctl start frobozz`.
		+ NOTE: All recent versions of `systemctl` assume the `.service` suffix if left off the service name. For example, `systemctl start frobozz.service` is the same as `systemctl start frobozz`.

		`[cols=",,",options="header",]`
		`\|===`
		`@@ -21,7 +21,7 @@`
		\|`service frobozz status`\|`systemctl status frobozz`\|Tells whether a service is currently running.

		\|`ls /etc/rc.d/init.d/`\|`systemctl` or `systemctl list-unit-files --type=service` or +
		- `ls /lib/systemd/system/.service /etc/systemd/system/.service`\|Used to list the services that can be started or stopped +
		+ `ls /lib/systemd/system/\.service /etc/systemd/system/.service`\|Used to list the services that can be started or stopped +
		`Used to list all the services and other units`

		\|`chkconfig frobozz on`\|`systemctl enable frobozz`\|Turn the service on, for start at next boot, or other trigger.
		`@@ -39,4 +39,4 @@`
		\|`chkconfig frobozz --add`\|`systemctl daemon-reload`\|Used when you create a new service file or modify any configuration
		`\|===`

		- NOTE: All `/sbin/service` and `/sbin/chkconfig` commands listed in the table continue to work on systemd-based systems and are translated to native equivalents as necessary. The only exception is `chkconfig --list`.
		+ NOTE: All `/sbin/service` and `/sbin/chkconfig` commands listed in the table continue to work on _systemd_-based systems and are translated to native equivalents as necessary. The only exception is `chkconfig --list`.

modules/ROOT/pages/understanding-and-administering-systemd.adoc

file modified

+7 -8

		`@@ -4,10 +4,9 @@`

		`[id='understanding-and-administering-systemd']`
		`= Understanding and administering systemd`
		`+ :toc:`

		`- include::{partialsdir}/unreviewed-message.adoc[]`
		`-`
		`- Learn the basic principles of systemd: how to configure it and use to administer the system.`
		`+ Learn the basic principles of the _systemd_ init system: how to configure it and use it to administer the system.`

		`include::{partialsdir}/con_understanding-systemd.adoc[leveloffset=+1]`

		`@@ -26,14 +25,14 @@`
		`include::{partialsdir}/ref_mapping-service-commands.adoc[leveloffset=+1]`


		`- [discrete]`
		`== Additional resources`

		`* http://www.freedesktop.org/wiki/Software/systemd[Project homepage]`
		`- * http://0pointer.de/blog/projects/ - Lennart's blog has lots of information about systemd. Lennart is the primary systemd developer`
		`- * http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions`
		`- * http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks`
		`- * https://fedoraproject.org/wiki/Features/systemd[ Features Fedora 15:systemd]`
		`+ * http://0pointer.de/blog/[Lennart Poettering's blog] with lots of information about _systemd_. Lennart is the primary _systemd_ developer`
		`+ * http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions[freedesktop.org's _systemd_ FAQ]`
		`+ * http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks[freedesktop.org's _systemd_ Tips & Tricks]`
		`* http://fosdem.org/2011/interview/lennart-poettering.html[Interview with the developer]`
		`+`
		`ifdef::parent-context[:context: {parent-context}]`
		`ifndef::parent-context[:!context:]`
		`+`

lcts commented 3 years ago

The existing doc was mostly fine.

changed the "Modifying existing systemd services" section to use systemctl edit instead of directly creating/modifying override files
added Table of Contents
updated/fixed links/descriptions in Additional Resources
fixed minor errors, typos, formatting, some rewording

rebased onto b4f8f6480134119abf36558e28c5790fc1f1775d

3 years ago

Metadata Update from @pbokoc:
- Request assigned

3 years ago

pbokoc commented 3 years ago

Thanks! Everything looks fine except for one little bit: In ref_mapping-service-commands.adoc, on line 24, since there are two * characters on the same line, Antora interprets it as markup for bold text so the asterisks don't render. Escape one of them as \* and it'll be fine.

pbokoc commented 3 years ago

Oh also, just a general comment - when you're submitting a PR that fixes an issue, could you please reference it in a comment in the PR so it's easier for me to find? I.e. "fixes #198".

1 new commit added

fix literal * being interpreted as markup

3 years ago

lcts commented 3 years ago

In ref_mapping-service-commands.adoc, on line 24, since there are two * characters on the same line, Antora interprets it as markup for bold text so the asterisks don't render. Escape one of them as * and it'll be fine.

Done.