commit 099306430f5219b5f5805368f6052f920af3c260
author Andrew Jeffery <andrew@aj.id.au> Thu Jun 08 16:11:53 2023 +0930
committer Andrew Jeffery <andrew@aj.id.au> Mon Jun 12 21:53:07 2023 +0000
tree 3d4d9a95900c3b905713ee849c4fe745ad3c9e71
parent 1dc30e8b30f95f6c5a4fbe91ec6e68857857c320

meta-ibm: first-boot-disable-ipmi-net: Improve performance

The documentation for systemctl's `disable` verb[1] states:

> This command implicitly reloads the system manager configuration after
> completing the operation. Note that this command does not implicitly
> stop the units that are being disabled. If this is desired, either
> combine this command with the --now switch, or invoke the stop command
> with appropriate arguments later.

[1]: https://www.man7.org/linux/man-pages/man1/systemctl.1.html

In simulation, reloads get expensive as they involve a bunch of IO.
During boot, under qemu, such a reload can take on the order of 15
seconds.

Further, Andrew Geissler states (no reference, private slack):

> The service-config-manager is responsible for enabling and disabling
> IPMI. On startup, it looks for the service and socket files via
> systemd d-bus queries and caches in a file, /etc/srvcfg-mgr.json. If
> you don’t run the services once on a fresh startup,
> service-config-manager never sees them and therefore never provides a
> way to enable/disable them. So on a fresh factory reset boot, you let
> them start, service-config-manager sees them and caches them, and then
> you disable them from there on out.

As evidenced by the `After` statements in the unit, the expectation is
that the units we're disabling have already been started.

The documentation for systemctl's `mask` verb[1] provides a useful
perspective:

> Mask one or more units, as specified on the command line. This will
> link these unit files to /dev/null, making it impossible to start
> them. This is a stronger version of disable, since it prohibits all
> kinds of activation of the unit, including enablement and manual
> activation.

The key insight here is the `disable` keyword tends to best be used to
prevent the unit from being started as part of a given target, e.g. the
default target.

Given that we would only need to reload the systemd configuration to
prevent the units from being started as part of a default target, and
the fact that they must have already been started in accordance with
`After` directive, there's no need to force an immediate reload of the
systemd configuration upon disabling the units. Further, it's possible
to combine the stop and the disable operation into one with `--now` as
demonstrated in the `disable` documentation above. And finally, as the
disable verb takes a unit PATTERN and not a singular unit, we can
compress the operation down to a single invocation.

Tested:

1. Booted up fresh p10bmc (factory reset), verified IPMI disabled by
   default via Redfish API
2. Enabled IPMI via Redfish API, verified bmcweb indicated IPMI enabled
   and services running
3. Rebooted BMC, verified IPMI was still enabled after BMC reboot
4. Disabled IPMI over Redfish, rebooted BMC, confirmed IPMI was still
   disabled

Change-Id: I0926e9d16a56c2f022e415f4f40c35695dd155b8
Tested-by: Andrew Geissler <geissonator@yahoo.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>