diff options
| author | Andrew Geissler <andrewg@us.ibm.com> | 2017-08-01 16:00:27 -0500 |
|---|---|---|
| committer | Patrick Williams <patrick@stwcx.xyz> | 2017-08-15 04:41:33 +0000 |
| commit | bfe9cc909ef31c6260abaa828d4271e748cf6488 (patch) | |
| tree | 954b79097494b2cbf2a100520bb7933ecd1a3b49 | |
| parent | e9d81af62d96a5a7d9a65576c5b51248141e3ce3 (diff) | |
| download | openbmc-docs-bfe9cc909ef31c6260abaa828d4271e748cf6488.tar.gz openbmc-docs-bfe9cc909ef31c6260abaa828d4271e748cf6488.zip | |
Update to reflect target refactoring work
- Action targets now obmc-<host|chassis>-<action>@.target
- New reboot target added to handle host reboots
Change-Id: Ib1e7fcefc254904a150cc77666cd617e1c2c07d1
Signed-off-by: Andrew Geissler <andrewg@us.ibm.com>
| -rw-r--r-- | openbmc-systemd.md | 47 |
1 files changed, 30 insertions, 17 deletions
diff --git a/openbmc-systemd.md b/openbmc-systemd.md index 1a91ce7..0864709 100644 --- a/openbmc-systemd.md +++ b/openbmc-systemd.md @@ -33,30 +33,29 @@ Within Phosphor OpenBMC, obmc-standby.target is wanted by multi-user.target and is where you'll find all Phosphor services associated. ## Server Power On -When OpenBMC is used within a server, the [obmc-chassis-start@.target](https://github.com/openbmc/openbmc/blob/171031d20c7ed03900739d51ba53ad0001f98fa5/meta-phosphor/common/recipes-core/systemd/obmc-targets/obmc-chassis-start%40.target) +When OpenBMC is used within a server, the [obmc-host-start@.target](https://github.com/openbmc/openbmc/blob/171031d20c7ed03900739d51ba53ad0001f98fa5/meta-phosphor/common/recipes-core/systemd/obmc-targets/obmc-host-start%40.target) is what drives the boot of the system. -If you dig into its .wants relationship, you'll see the following in the file +If you dig into its .requires relationship, you'll see the following in the file system ``` -ls -1 /lib/systemd/system/obmc-chassis-start@0.target.wants/ -obmc-power-chassis-on@0.target -obmc-start-host@0.service -... +ls -1 /lib/systemd/system/obmc-host-start@0.target.requires +obmc-chassis-poweron@0.target +start_host@0.service ``` -You can see we have another target in here, obmc-power-chassis-on@0.target, -along with some services that will all be started by systemd when you do a -"systemctl start obmc-chassis-start@0.target". +You can see we have another target in here, obmc-chassis-poweron@0.target, +along with a service that will all be started by systemd when you do a +"systemctl start obmc-host-start@0.target". The target has corresponding services associated with it: ``` -ls -1 /lib/systemd/system/obmc-power-chassis-on\@0.target.wants/ +ls -1 /lib/systemd/system/obmc-chassis-poweron\@0.target.requires/ op-power-start@0.service op-wait-power-on@0.service ``` -So basically, if you run `systemctl start obmc-chassis-start@0.target` then +So basically, if you run `systemctl start obmc-host-start@0.target` then systemd will start execution of all associated services. The services have dependencies within them that control the execution of each @@ -64,9 +63,22 @@ service (for example, the op-power-start.service will run prior to the op-wait-power-on.service). These dependencies are set using targets and the Wants,Before,After keywords. -## Server Power Off -The server power off function is encapsulated in the obmc-chassis-stop@0.target. -You can do a similar exercise with the power on to see its dependent services. +## 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 +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 +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. +This target will utilize the soft power off target and then, once that +completes, start the host power on target. ## Systemd Control in OpenBMC There are a collection of services within OpenBMC that interact with systemd and @@ -81,7 +93,7 @@ the following: xyz.openbmc_project.State.Host RequestedHostTransition s xyz.openbmc_project.State.Host.Transition.On -Underneath the covers, this is calling systemd with obmc-chassis-start@0.target +Underneath the covers, this is calling systemd with the server power on target. ## Error Handling of Systemd With great numbers of targets and services, come great chances for failures. @@ -123,8 +135,8 @@ the halt vs. automatic reboot functionality. 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-power-chassis-on@0.target, will have a -"OnFailure=obmc-power-chassis-off@%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 @@ -150,3 +162,4 @@ obmc-chassis-start@.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. + |

