#
8c90f319 |
| 09-May-2023 |
Andrew Geissler <geissonator@yahoo.com> |
systemd: no installation in templated targets
Upstream yocto introduced a change via e510222 (systemd-systemctl: fix instance template WantedBy symlink construction).
This fixes a bug that we in Op
systemd: no installation in templated targets
Upstream yocto introduced a change via e510222 (systemd-systemctl: fix instance template WantedBy symlink construction).
This fixes a bug that we in OpenBMC had been taking advantage of in that we were able to document our templated target dependencies without it actually doing anything. The real installation of services within targets occurs in our bitbake recipes due to the complexity of chassis and host instances on a per machine basis.
Leave the dependency information in the service files but comment them out. It's useful to be able to look at a service and understand which targets it's going to be installed into by the bitbake recipes.
In some cases, we had hard coded the target instance, which does install the service correctly, but only in that one target. All services should be installed via the bitbake recipe to ensure the service is properly installed in all instances of the target. Once the bump for this commit goes into openbmc/openbmc, I will ensure the recipe is updated to install all services correctly.
Change-Id: Ie8ec6b5fabe196bac669187ce50ee3b13262c98f Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
show more ...
|
#
dc777fa2 |
| 06-May-2022 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Host reboot should not redo operations
While powering on the host, a "warm reboot" of the host may occur one or more times. For example, the host boot process may update hardware in a w
regulators: Host reboot should not redo operations
While powering on the host, a "warm reboot" of the host may occur one or more times. For example, the host boot process may update hardware in a way that requires a host reboot.
During a "warm reboot" of the host, power to the chassis remains on. As a result, the following regulator operations should *not* be performed: * Configuring the regulators again. * Disabling and then re-enabling regulator monitoring for sensors and redundant phase faults.
Modify several regulator systemd service files so that those regulator operations are not performed during a "warm reboot" of the host.
Test Plan: * https://gist.github.com/smccarney/c2eea054b7439b84b55f4fb89f474413
Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I5e4c97168f0f7cdd5d7d6bfed227c5769a86d5a8
show more ...
|
#
d1307294 |
| 19-Apr-2022 |
Zev Weiss <zev@bewilderbeest.net> |
regulators: Add phosphor-regulators service dependencies
'regsctl' can't do anything useful until phosphor-regulators is running, so add systemd unit dependencies to ensure it's started before regul
regulators: Add phosphor-regulators service dependencies
'regsctl' can't do anything useful until phosphor-regulators is running, so add systemd unit dependencies to ensure it's started before regulators-config and regulators-monitor-{enable,disable}.
While we're at it, change phosphor-regulators.service to be of type dbus so we get a more meaningful check that it's really up and running, and tweak the instantiation of ManagerObject so that it emits the necessary signals.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net> Change-Id: I724e4f335c4347ad6789e2d68cfb58c6387e6073
show more ...
|
#
e97fc13a |
| 14-Sep-2021 |
Shawn McCarney <shawnmm@us.ibm.com> |
regulators: Fix race condition in monitor disable There is a systemd service file that disables regulator monitoring when the chassis is powered off. This is necessary because we do not
regulators: Fix race condition in monitor disable There is a systemd service file that disables regulator monitoring when the chassis is powered off. This is necessary because we do not want to read sensor values or check for phase faults when the chassis is powered off. Monitoring needs to stop before the regulators are disabled/turned off. The service file currently does not specify a 'Type', which means that it defaults to Type 'simple'. Service files of this Type are considered started when they fork the specified executable. That is, systemd does not wait for the executable to complete. In this case, we need the executable to complete. The service runs the regsctl executable, which makes a D-Bus method call to the regulators application disabling monitoring. We need this D-Bus method to complete before proceeding with the power off. Otherwise there is a race condition between the following: * The timers that initiate sensor and phase fault monitoring could expire, causing unwanted monitoring to occur during power off. * The regsctl executable could complete the D-Bus call, stopping monitoring and the associated timers. The solution is to set the Type of the service file to 'oneshot'. This causes systemd to wait until the executable completes. Signed-off-by: Shawn McCarney <shawnmm@us.ibm.com> Change-Id: I399a2a4ba7f1a256c42a7e9b8b036abd1b077033
show more ...
|
#
01bc6120 |
| 29-Jan-2020 |
Matthew Barth <msbarth@us.ibm.com> |
regs: Add/install monitor disable service Create a service file to call a method within the phosphor-regulators binary to disable monitoring of the regulators. Add this service file to
regs: Add/install monitor disable service Create a service file to call a method within the phosphor-regulators binary to disable monitoring of the regulators. Add this service file to be installed within the systemd services directory(`/lib/systemd/system/`). Tested: Disable of monitoring is called the earliest after a request to poweroff Signed-off-by: Matthew Barth <msbarth@us.ibm.com> Change-Id: Idd8ad73c807faddc90a7d86fd09da0508d5461dd
show more ...
|