systemd: be consistent with target formatting
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I141a54d2bafbd18c1103f893d9fcef79b9e199b7
diff --git a/architecture/openbmc-systemd.md b/architecture/openbmc-systemd.md
index c7123d9..f31d1af 100644
--- a/architecture/openbmc-systemd.md
+++ b/architecture/openbmc-systemd.md
@@ -28,9 +28,9 @@
## Initial Power
When an OpenBMC system first has power applied, it starts the "default.target"
unless an alternate target is specified on the kernel command line. In
-Phosphor OpenBMC, there is a link from default.target to multi-user.target.
+Phosphor OpenBMC, there is a link from `default.target` to `multi-user.target`.
-You'll find all the phosphor services associated with multi-user.target.
+You'll find all the phosphor services associated with `multi-user.target`.
## Server Power On
When OpenBMC is used within a server, the [obmc-host-start@.target](https://github.com/openbmc/phosphor-state-manager/blob/master/target_files/obmc-host-start%40.target)
@@ -84,18 +84,18 @@
## Server Power Off (Soft)
The soft server power off function is encapsulated in the
-obmc-host-shutdown@.target. This target is soft in that it notifies the host
+`obmc-host-shutdown@.target`. This target is soft in that it notifies the host
of the power off request and gives it a certain amount of time to shut itself
down.
## Server Power Off (Hard)
The hard server power off is encapsulated in the
-obmc-chassis-hard-poweroff@.target. This target will force the stopping
+`obmc-chassis-hard-poweroff@.target`. This target will force the stopping
of the soft power off service if running, and immediately cut power to the
system.
## Server Reboot
-The reboot of the server is encapsulated in the obmc-host-reboot@.target.
+The reboot of the server is encapsulated in the `obmc-host-reboot@.target`.
This target will utilize the soft power off target and then, once that
completes, start the host power on target.
@@ -170,30 +170,30 @@
Targets which are not host related, will need special thought in regards to
their error handling. For example, the target responsible for applying chassis
-power, obmc-chassis-poweron@0.target, will have a
-"OnFailure=obmc-chassis-poweroff@%i.target" error path. That is, if the
+power, `obmc-chassis-poweron@0.target`, will have a
+`OnFailure=obmc-chassis-poweroff@%i.target` error path. That is, if the
chassis power on target fails then power off the chassis.
The above info sets up some general **guidelines** for our host related
targets and services:
-- All targets should have an "OnFailure=obmc-quiesce-host@.target"
+- All targets should have a `OnFailure=obmc-quiesce-host@.target`
- All services which are required for a target to achieve its function should
be RequiredBy that target (not WantedBy)
- All services should first try to be "Type=oneshot" so that we can just rely on
the target failure path
- If a service can not be "Type=oneshot", then it needs to have a
-"OnFailure=obmc-quiesce-host@.target" and ideally set "RemainAfterExit=no"
+`OnFailure=obmc-quiesce-host@.target` and ideally set "RemainAfterExit=no"
(but see caveats on this below)
- If a service can not be any of these then it's up to the service application
-to call systemd with the obmc-quiesce-host@.target on failures
+to call systemd with the `obmc-quiesce-host@.target` on failures
### RemainAfterExit
This is set to "yes" for most OpenBMC services to handle the situation where
someone starts the same target twice. If the associated service with that
target is not running (i.e. RemainAfterExit=no), then the service will be
executed again. Think about someone accidentally running the
-obmc-chassis-poweron@.target twice. If you execute it when the operating system
+`obmc-chassis-poweron@.target` twice. If you execute it when the operating system
is up and running, and the service which toggles the pgood pin is re-executed,
you're going to crash your system. Given this info, the goal should always be
to write "oneshot" services that have RemainAfterExit set to yes.