sensor-monitor: Correct shutdown propertiesChanged matches

The wrong shutdown type was associated to the defined propertiesChanged
matches. It appears this had no affect on receiving these signals a

sensor-monitor: Correct shutdown propertiesChanged matches

The wrong shutdown type was associated to the defined propertiesChanged
matches. It appears this had no affect on receiving these signals as
long as both hard & soft threshold interfaces were implemented on a
system since after receiving the signal, the data in the signal is used
to determine which threshold changed.

Change-Id: I64b44ca474fe2a5049774b0018787c6016c35691
Signed-off-by: Matthew Barth <msbarth@us.ibm.com>

show more ...

sensor-monitor: Fix missing function prototype

Add the missing ThresholdAlarmLogger::interfacesRemoved function
prototype. This passed CI because the --enable-sensor-monitor flag
must not be turned

sensor-monitor: Fix missing function prototype

Add the missing ThresholdAlarmLogger::interfacesRemoved function
prototype. This passed CI because the --enable-sensor-monitor flag
must not be turned on.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I5ad5617bd56ae6649d6adde31faa02f9326d0483

show more ...

sensor-monitor: Catch sdbusplus::exception

Check for a threshold alarm D-Bus property fail read by looking for an
sdbusplus exception instead of one of the built in fan exceptions.

The SdBusPlus wr

sensor-monitor: Catch sdbusplus::exception

Check for a threshold alarm D-Bus property fail read by looking for an
sdbusplus exception instead of one of the built in fan exceptions.

The SdBusPlus wrapper call used here to get the property doesn't throw
any of the fan custom exceptions, and there are cases when the call can
fail, like when entity-manager only defines a high threshold and not a
low one for a sensor so the low alarm property won't be on D-Bus.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I19332603a373436f68ba075844fa3436787ef8b0

show more ...

sensor_monitor: Watch for interfacesRemoved

Now that the hwmontempsensor app can remove sensors from D-Bus when the
entity-manager config goes away, the sensor monitor needs to deal with
it. It doe

sensor_monitor: Watch for interfacesRemoved

Now that the hwmontempsensor app can remove sensors from D-Bus when the
entity-manager config goes away, the sensor monitor needs to deal with
it. It does so by watching for a threshold interface to be removed from
a sensor and removing that entry from its map of alarms to watch.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I6b48b20eb4d158e5e44566e46469421550d21686

show more ...

sensor:monitor: Use a single PowerState object

Now that both monitor classes need to know about power state, change
them to keep a shared_ptr to a PowerState object and then pass the
object into the

sensor:monitor: Use a single PowerState object

Now that both monitor classes need to know about power state, change
them to keep a shared_ptr to a PowerState object and then pass the
object into their constructors.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia83217e8af51204bbb3fc6e8e3f2eac5912b5913

show more ...

sensor-monitor: Threshold events only when on

Update the monitor that creates event logs for threshold alarms to only
create them when system power is on. When system power changes to on,
the code

sensor-monitor: Threshold events only when on

Update the monitor that creates event logs for threshold alarms to only
create them when system power is on. When system power changes to on,
the code will look for any active alarms to create event logs for. If
an alarm deasserts when power is off, the informational event log will
not be created.

While it could be argued that if event logs aren't desired when power is
off then sensors shouldn't even be active on D-Bus then, there are
cases where it could still be useful to see the sensor value and even an
asserted threshold alarm on Redfish then, such as inlet temp and
altitude/pressure.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I34ce6d26d06dbf1d7cabc184074c0c1f6be65d49

show more ...

sensor-monitor: Capture PID in event logs

Pass the PID of the process into an event log with the _PID additional
data entry. This gets done automatically when the report() or commit()
phosphor-logg

sensor-monitor: Capture PID in event logs

Pass the PID of the process into an event log with the _PID additional
data entry. This gets done automatically when the report() or commit()
phosphor-logging event log library functions are called, but needs to be
done manually when the D-Bus API is used. This just provides a way to
see which process created the event log and I just forgot to do this
when I first wrote it..

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I094a0eb9634df53759f257799ae518ffd63e45cd

show more ...

sensor-monitor: Changes for power off error

The hard and soft shutdown alarm errors are posted twice when a system
shuts down due to those thresholds being exceeded, once when the
threshold is first

sensor-monitor: Changes for power off error

The hard and soft shutdown alarm errors are posted twice when a system
shuts down due to those thresholds being exceeded, once when the
threshold is first exceeded, and again when the shutdown actually
occurs. For these errors, make the following changes that will
differentiate them from the first time they were logged:

1. Change severity to Critical
2. Set POWER_THERMAL_CRITICAL_FAULT=TRUE in the additional data
3. Set SEVERITY_DETAIL=SYSTEM_TERM in the additional data

Certain implementations, such as the IBM one, will take additional
actions based on these changes.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I94a1cc9dad492e78f59619c4012bcaf6a4c81431

show more ...

docs: Main README updates

Overhaul and update the main README for the package to list all
applications supported and the details of each application at their
current state. Most time was spent on up

docs: Main README updates

Overhaul and update the main README for the package to list all
applications supported and the details of each application at their
current state. Most time was spent on updating/aligning the use of JSON
based configuration since support for YAML configs has been deprecated
and will eventually be removed entirely.

Signed-off-by: Matthew Barth <msbarth@us.ibm.com>
Change-Id: Ifc8409261b2f50a77d47ffba46e41f25e3cf2c6c

show more ...

sensor-mon: Create event logs

Fill in the function to create event logs. It creates a different log
for an alarm set versus an alarm clear.

The code will not create event logs for sensors of type

sensor-mon: Create event logs

Fill in the function to create event logs. It creates a different log
for an alarm set versus an alarm clear.

The code will not create event logs for sensors of type 'utilization'
because the application that provides CPU and memory utilization
thresholds hardcodes the threshold values and high CPU usage is expected
in some cases, like during a code update. If someone does want these
event logs from those alarms then that can be fixed up in the future.

There is also a FRU callout added for the sensor's FRU. This is done by
following an association, either 'inventory' or 'chassis', depending on
what application provided the sensor. While the sensor documentation
states that the 'inventory' association would be used to point to the
FRU, nothing in the dbus-sensors code does that and frankly trying to
make that happen isn't worth the effort at this point since it can work
how it is now.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I5689cb47250def28aa2b087f8b1975f5464eb98f

show more ...

sensor-mon: Handle propertiesChanged

Fill in the propertiesChanged handler to check if any event logs need to
be created.

When a sensor is added to D-Bus after this application starts, the code
see

sensor-mon: Handle propertiesChanged

Fill in the propertiesChanged handler to check if any event logs need to
be created.

When a sensor is added to D-Bus after this application starts, the code
sees it via the propertiesChanged signal. It knows its new because
there is no previous value saved, so it knows to only care about an
alarm value of true by making up a previous value of false.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I66571b6acaba180ab210cd41701014942d2dc050

show more ...

sensor-mon: Check for threshold alarms on startup

Add the functionality to the ThresholdAlarmLogger class to check for any
active alarms on startup and make a createEventLog() call for them.

It als

sensor-mon: Check for threshold alarms on startup

Add the functionality to the ThresholdAlarmLogger class to check for any
active alarms on startup and make a createEventLog() call for them.

It also keeps track of the alarm values so that the propertiesChanged
handler can know if an alarm changed state or is just new.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I0dec7fc7c42d5007c1466700470faefbf6976dff

show more ...

sensor-mon: Threshold alarm logger framework

Add the new class ThresholdAlarmLogger that will watch the Warning,
Critical, and PerformanceLoss sensor threshold D-Bus interfaces and
create event logs

sensor-mon: Threshold alarm logger framework

Add the new class ThresholdAlarmLogger that will watch the Warning,
Critical, and PerformanceLoss sensor threshold D-Bus interfaces and
create event logs when their alarm properties set and clear.

This commit just creates the class with its three sdbusplus match
objects to watch those interfaces.

Change-Id: I67c629bcabe059952c2029dc034daace9b88f051
Signed-off-by: Matt Spinler <spinler@us.ibm.com>

show more ...

sensor-mon: Add service file

The service file will start the sensor-monitor application on the way to
the multi-user target.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I366a07ce10f

sensor-mon: Add service file

The service file will start the sensor-monitor application on the way to
the multi-user target.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I366a07ce10ff6138c0a6d50a3dbaa8f7dfaed622

show more ...

sensor-mon: Add a readme

Added a bit of documentation that describes what the sensor-monitor
does. Also add some documentation on what the other applications in
this repository do as well.

Signed-

sensor-mon: Add a readme

Added a bit of documentation that describes what the sensor-monitor
does. Also add some documentation on what the other applications in
this repository do as well.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I1abd411786f1504cd5df623f6f7c5ba02056626d

show more ...

sensor-mon: Create event logs

Create phosphor-logging event logs when the alarms are tripped and
cleared. The severity will be 'Error' on trip, and 'Informational'
on clear.

The error names will b

sensor-mon: Create event logs

Create phosphor-logging event logs when the alarms are tripped and
cleared. The severity will be 'Error' on trip, and 'Informational'
on clear.

The error names will be xyz.openbmc_project.Sensor.Threshold.Error.
HardShutdownAlarmLow
HardShutdownAlarmLowClear
HardShutdownAlarmHigh
HardShutdownAlarmHighClear

When the shutdown occurs after the delay, the AlarmLow/AlarmHigh events
are sent again. This is so there is an event log that occurs at the
time of the shutdown, and it says what the problem was that caused it.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: If36c48e73f4208d781040c8b2c06995f66bebc20

show more ...

sensor-mon: Persist timer start times

It's possible that while a shutdown timer is running, this app or the
whole BMC may restart. In that case, we want to restart the timer with
only the remaining

sensor-mon: Persist timer start times

It's possible that while a shutdown timer is running, this app or the
whole BMC may restart. In that case, we want to restart the timer with
only the remaining time, assuming the alarm is still active.

To do this, create a new AlarmTimestamps class to hold any running timer
start times and persist these times using the cereal library. If the
application is restarted with timestamps written out and the alarm is
initially active and power is on, then the shutdown timer will be
calculated to be:
delay = shutdownDelay - (now - original time)

Note that cereal doesn't know how to handle the AlarmType or
ShutdownType types so they are converted to ints before writing.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: If07abe91c0e6951fcd74bbc49eb511a38f7b4006

show more ...

sensor-mon: Start timers and shutdown

When the threshold alarm is tripped, start a timer for the configured
amount of time. If the alarm clears before that time, stop the timer.
If it doesn't, powe

sensor-mon: Start timers and shutdown

When the threshold alarm is tripped, start a timer for the configured
amount of time. If the alarm clears before that time, stop the timer.
If it doesn't, power off the system.

Note that the alarm for the SoftShutdown threshold still does a hard
shutdown. That's because in the family of systems this was written for,
the hypervisor also gets an alert when the threshold trips and is the
one that drives the power off. The shutdown that this code does would
only occur when the hypervisor doesn't shut down first.

This could easily be wrapped in some sort of compile flags where the
default behavior would be to do a soft shutdown, but since at this point
there is no user of that the default will remain the way it is.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I3bc8f82562594dcd61bfcbc471ffe1a2d9451595

show more ...

sensor-mon: Handle propertiesChanged

Fill in the handler for a Threshold.HardShutdown or
Threshold.SoftShutdown property changing.

If the power is off, do nothing, otherwise read out the changed al

sensor-mon: Handle propertiesChanged

Fill in the handler for a Threshold.HardShutdown or
Threshold.SoftShutdown property changing.

If the power is off, do nothing, otherwise read out the changed alarm
properties and check if any action needs to be taken.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: I379e90dffe3e6d3acdf18820bda34f2a5671f57a

show more ...

sensor-mon: Create sensor-monitor application

This is a new application that will be used to take actions based on
sensor values or sensor threshold alarm values. It's not built unless
the --enable

sensor-mon: Create sensor-monitor application

This is a new application that will be used to take actions based on
sensor values or sensor threshold alarm values. It's not built unless
the --enable-sensor-monitor option is used.

The first behavior will be to do power offs and create event logs based
on the xyz.openbmc_project.Sensor.Threshold.HardShutdown and
SoftShutdown threshold interfaces that may be present on sensor object
paths. It will watch the high and low alarm properties on those
interfaces. This could then be used to power off the system after some
delay if some sensor value gets too high or low, such as a high ambient
or a low voltage.

This first commit in the series creates the application and a new
ShutdownAlarmMonitor class, which is where the monitoring will happen.
Initially, it just finds all existing soft and hard shutdown interfaces
on D-Bus and puts them in a map. It also registers for properties
changed signals for those interfaces.

Note that the interfacesAdded signal doesn't need to be used because all
sensor applications today emit propertiesChanged signals when they first
start up anyway.

Signed-off-by: Matt Spinler <spinler@us.ibm.com>
Change-Id: Ia5b82fcbe32f65d94b23bf26a025202a7f885183

show more ...