fix inheritance order of FaultLog

The destructor order is incorrect which caused the ObjectMapper to not
see all the interfaces removed... eventually causing OOM in Object
Mapper. Reorder it to make sure we remove the object in the right order.

https://stackoverflow.com/questions/31518581/order-of-destruction-in-the-case-of-multiple-inheritance

The InterfacesRemoved signal now remove all the interface added, so the
object mapper will remove the entry entirely instead of keeping it in
the hashmap.

```
signal time=1738283381.202322 sender=:1.3856 -> destination=(null destination) serial=466 path=/xyz/openbmc_project/dump; interface=org.freedesktop.DBus.ObjectManager; member=InterfacesRemoved
   object path "/xyz/openbmc_project/dump/faultlog/entry/44"
   array [
      string "org.freedesktop.DBus.Peer"
      string "org.freedesktop.DBus.Introspectable"
      string "org.freedesktop.DBus.Properties"
      string "xyz.openbmc_project.Dump.Entry.FaultLog"
      string "xyz.openbmc_project.Time.EpochTime"
      string "xyz.openbmc_project.Object.Delete"
      string "xyz.openbmc_project.Dump.Entry"
      string "xyz.openbmc_project.Common.Progress"
      string "xyz.openbmc_project.Common.OriginatedBy"
   ]
```

Tested: The logs are still detected by the ObjectMapper properly and
found via bmcweb.

```
$ curl -s http://localhost:80/redfish/v1/Managers/bmc/LogServices/FaultLog/Entries | jq ".Members | length"
273
```

Spamming of CEPR logs and now Object Mapper still does not increase the
memory usage significantly. Spammed for 6 hours+.

Start:

```
$ systemctl status xyz.openbmc_project.ObjectMapper
● xyz.openbmc_project.ObjectMapper.service - Phosphor DBus Service Discovery Manager
     Loaded: loaded (/usr/lib/systemd/system/xyz.openbmc_project.ObjectMapper.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-01-31 01:08:27 PST; 12s ago
 Invocation: 6e615edea66e4351baa132533d2ccdc0
   Main PID: 3285 (mapperx)
     Memory: 4.3M
        CPU: 2.470s
     CGroup: /system.slice/xyz.openbmc_project.ObjectMapper.service
             └─3285 /tmp/mapperx
```

End:

```
$ systemctl status xyz.openbmc_project.ObjectMapper
● xyz.openbmc_project.ObjectMapper.service - Phosphor DBus Service Discovery Manager
     Loaded: loaded (/usr/lib/systemd/system/xyz.openbmc_project.ObjectMapper.service; enabled; preset: enabled)
     Active: active (running) since Fri 2025-01-31 01:08:27 PST; 6h ago
 Invocation: 6e615edea66e4351baa132533d2ccdc0
   Main PID: 3285 (mapperx)
     Memory: 8.1M
        CPU: 29min 15.200s
     CGroup: /system.slice/xyz.openbmc_project.ObjectMapper.service
             └─3285 /tmp/mapperx
```

Fusion-Link: fusion2 link N/A. This change doesn't affect exiting presubmit tests.
Google-Bug-Id: 393174995
Platforms-Affected: All gBMC
Change-Id: I731d4421e29672696294f2c9eec99fce2f744c19
Signed-off-by: Willy Tu <wltu@google.com>
(cherry picked from commit 460a5269327b21ce93192d1619fe138caaf6231a)
1 file changed
tree: f89cf002f88afd8a4b03ec8c766c85dd6f4c52db
  1. classes/
  2. conf/
  3. dynamic-layers/
  4. recipes-bsp/
  5. recipes-connectivity/
  6. recipes-core/
  7. recipes-devtools/
  8. recipes-extended/
  9. recipes-google/
  10. recipes-kernel/
  11. recipes-phosphor/
  12. recipes-support/
  13. recipes-tpm1/
  14. recipes-tpm2/
  15. LICENSE
  16. README.md
README.md

meta-gbmc-staging

This repository contains additions to the openbmc/meta-google layer that are not yet ready for OpenBMC inclusion.

How to use this layer

  1. Clone openbmc/openbmc from GitHub.
  2. Clone this layer from GitHub into a subdirectory of openbmc.