The initialization order of EventServiceManager and persistent_data::ConfigFile does not appear to be guaranteed.

[lijl44]

Is this the right place to submit this?

• This is not a security vulnerability or a crashing bug
• This is not a question about how to use OpenBMC
• This is not a bug in an OpenBMC fork or a bug in code still under code review.
• This is not a request for a new feature.

Bug Description

EventServiceManager is initialized at construct time to read persistent data from EventServiceStore. But the data in EventServiceStore is written by persistent_data::ConfigFile at initialization time.

So I think persistent_data::ConfigFile should be initialized earlier than EventServiceManager.

bmcweb initializes EventServiceManager very early in the run() function. but I didn't find code to explicitly initialize persistent_data::ConfigFile before EventServiceManager initialization, which would cause bmcweb to lose the event configuration. (maybe I didn't find the relevant code)

Could you help confirm this? Thanks.

Version

4c8c12d2a699641ec24a2605583686a03a8484cb

Additional Information

No response

[edtanous]

Does this behavior cause an actual functional issue in the image? If so, how do you reproduce it?

ConfigFile class is initialized in the constructor, here:

bmcweb/include/persistent_data.hpp

Line 33 in cf91c8c

readData();

So it's not clear to me what a fix would even look like.

[lijl44]

In short, I think I need to call persistent_data::getConfig(); explicitly after loadOldBehavior(); to initialize EventServiceStore, otherwise it will lead to loss of subscription information after restarting bmcweb.

[edtanous]

lead to loss of subscription information after restarting bmcweb.

Can you write this down to a set of steps to reproduce the issue?

[edtanous]

@lijl44 any updates here?