tree 3019aa0acb33d1087561d8c4d26f24204ef2a7af
parent 928bbf15cb7658d06c53cf22b9e40b9a2d2a7907
author Andrew Geissler <geissonator@yahoo.com> 1676507014 -0600
committer Andrew Geissler <geissonator@yahoo.com> 1677092494 -0600

increase timeout on systemd Subscribe method call

An issue was recently hit in IBM manufacturing where this call to the
Subscribe method provided by systemd returned a dbus timeout. The
phosphor-host-state-manager service was restarted and the call then
passed, but by this time the first fail generated a core dump
and resulted in a BMC Quiesced state.

The situation is not easily recreatable and was only seen on our largest
configured systems, and only after a factory reset.

No searching of systemd bugs has turned up anything in this area so it
appears to be specific to OpenBMC. Most likely related to our embedded
env and large amount of services started during BMC startup, especially
after a factory reset.

Worst case time on our max configured system was around 30s so double
that and make it our timeout for this call.

Tested
- Basic good path testing to ensure no regressions
- 100+ factory resets done on a variety of systems to ensure the timeout
  was no longer seen

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