psusensor crashing due to activating already-active sensors
ijsn-20 opened this issue · comments
I've been observing that psuserver is crashing and re-starting for our system when the chassis first powers on, and I've narrowed it down to the service trying to open()
the sensors' sysfs files when they're already open.
Here's how the issue manifests, as I understand it:
- psusensor service first initializes, PSUSensorMain.cpp calls
createSensors()
which callscreateSensorsCallback()
, which will create a sensor object for the sensor map that firstopen()
s the associated sysfs file as part of its constructor - Then, when chassis_state_manager.cpp receives signal that power ON is complete (in
Chassis::sysStateChange()
), it setsxyz.openbmc_project.State.ChassisCurrentPowerStatus
toChassisOn
, which then sends aorg.freedesktop.DBus.Properties.PropertiesChanged
signal to thechassisMatch
callback function in dbus-sensors Utils.cpp. - The callback checks to see if
ChassisCurrentPowerStatus
equalsChassisOn
(Which I think it always would, if this signal is tied to changing theChassisCurrentPowerStatus
property), and if so, it sets theon
variable to true (https://github.com/openbmc/dbus-sensors/blob/master/src/Utils.cpp#L526). - After that it calls the
powerStateChanged()
function in PSUSensorMain.cpp (which was assigned tohostStatusCallback
in https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L1221), with thenewState
argument passed as true (based on theon
variable). BecausenewState
is true,createSensors()
is called withactivateOnly
set to true; and because we have a corresponding sensor object for each sensor in the map (and not a nullptr), it will callsensor->activate
(without checking to see if it alreadyisActive()
). (https://github.com/openbmc/dbus-sensors/blob/master/src/PSUSensorMain.cpp#L928) - This will
open()
a file that's already open, which will cause PSUSensor to terminate itself. It can then recover and run normally, because the chassis is now on
I was wondering if this had been observed by anyone else, or if it's isolated to our configuration. The only changes we have to entity-manager are adding per-sensor power states to schemas/legacy.json, but even without these changes the issue is still observed. One method we had been using to prevent this was to only call sensor->activate()
if sensor->isActive()
returns false, but I didn't know if there was a more underlying problem at hand.
I encountered this problem in hwmontempsensor as well:
- If the
power off
signal is sent after thepower on
timer callback and beforeopen()
increatesensors()
, thetimer.cancel()
will fail, and the sysfs file will be closed and then opened. - If the
chassis off
signal is sent afterchassis on
callbackcreatesensors()
, the sysfs file will be opened again, leading to a crash.