tree 87f0cf2bfce4e462078a22e564b3342a30e44e98
parent 8425624a9046f5a853e8596cc74441e622028494
author George Liu <liuxiwei@ieisystem.com> 1729738987 +0800
committer George Liu <liuxiwei@ieisystem.com> 1729759978 +0800

Fix the coredump problem caused by lock acquisition failure

As net-ipmid depends on ipmid, stress testing found that frequent
start/stop of net-ipmid will cause coredump due to lock acquisition
failure in ipmid's inithannelPersistData.
Since net-ipmid depends on ipmid, stress testing found that if
net-ipmid is started/stopped frequently, it will exit abnormally due
to failure to obtain the lock in the inithannelPersistData method of
ipmid.
```
netipmid-eth1[893]: terminate called after throwing an instance of ‘boost::interprocess::lock_exception’
netipmid-eth1[893]:     what():     boost::interprocess::lock_exception
```

Because in the main method of net-ipmid, the ipmi::ipmiChannelInit
method is called first, and then the startEventLoop method is called
to process the signal. This will cause a bug:
1. After net-ipmid@eth0 starts, ipmi::ipmiChannelInit will be
   executed to initialize and construct ChannelConfig.
2. The initChannelPersistData method will be executed in the
   construction method to obtain the lock and load the configuration.
3. If the stop method of net-ipmid is executed before the
   construction method is completed, the held lock will not be
   released correctly
4. If start is executed immediately at this time, the ipmid process
   will coredump because the current lock is undefined.

This submission moves the signal processing to before the
ipmi::ipmiChannelInit method, which will ensure that if net-ipmid
starts and captures abnormal operations, it will stop io first, so
that the held lock will be released correctly.

Tested:
Using this patch, no ipmid coredump occurs in the stress test.

Signed-off-by: George Liu <liuxiwei@ieisystem.com>
Change-Id: I29694405679330c083fa35d04443fb2e31bfca3b