transition: ensure only run once per power on/off

Some situations have arisen where a user requests a power off or on when
the system is already in that state. That results in these services
re-runn

transition: ensure only run once per power on/off

Some situations have arisen where a user requests a power off or on when
the system is already in that state. That results in these services
re-running and setting the state to transition even though the system is
actually off or on already.

The solution is to ensure these services only run once and do not stop
until a Conflicts occurs to stop it.

Tested:
- Verified service only runs once now even if started multiple times
- Verified when conflicting target runs that you can start service again

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I2aa866057fca9c1743385f0d5f3beff5899e4c15

show more ...

host state transitioning support

The following commit has some relevant background:
https://github.com/openbmc/phosphor-dbus-interfaces/commit/9f65dfeaa5ab22cae03db45c9916868da9864f83

The new servi

host state transitioning support

The following commit has some relevant background:
https://github.com/openbmc/phosphor-dbus-interfaces/commit/9f65dfeaa5ab22cae03db45c9916868da9864f83

The new services introduced in this commit will set these new transition
states. They will work together with the existing state-manager
infrastructure in that the new services will set the transitions when
the targets start and the current software which looks for the targets
to complete will update the state to the official Running/Off.

But why not just have the existing software that monitors for the
targets to complete also monitor for them to start? This was a long and
dark hole I went down for a while. In the end, systemd D-Bus signals do
not provide enough information on target starts. The signals let you
know that "something" is going to happen to the target you're interested
in, but not the details. For example, if you start the
obmc-host-start@.target, you get two systemd notifications that indicate
"something" is going to happen to obmc-host-start@.target and also that
"something" is going to happen to obmc-host-stop@.target. This is
because when one target starts, it stops the other. Since they are both
just queued for "something" there's no mechanism to interrogate them for
which one is doing what. I tried a lot of different things here but
just couldn't get anything that covered all paths. The maintainers of
systemd have indicated on their mailing list that they are not
interested in enhancing the signal data because they feel like it would
be a rat hole of never ending data getting added to it.

Tested:
- Built into an image and verified CurrentHostState changed as expected
doing a host on, off, and reboot.

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Id2e9bd0394fc71944d26ce4bd40b136acf82b5e4

show more ...