diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2024-02-14 20:32:53 +0300 |
|---|---|---|
| committer | Andrew Geissler <geissonator@yahoo.com> | 2024-02-14 21:48:15 +0300 |
| commit | e143c93c9c8fe582ea98febf18f0148ca0bfc6d9 (patch) | |
| tree | 6e18b96a1c214fc3052dfafbae44fd75eefe8fa5 /meta-phosphor/classes | |
| parent | de0c27ed80e102b14d4e8dbec9020380fb0b4369 (diff) | |
| download | openbmc-e143c93c9c8fe582ea98febf18f0148ca0bfc6d9.tar.xz | |
mmc-init.sh: ensure only one udevd running
Recently the following error started popping up in the journal:
```
Jan 04 07:53:25 p10bmc systemd-coredump[174]: Due to PID 1 having crashed coredump collection will now be turned off.
Jan 04 07:53:25 p10bmc systemd-coredump[174]: Resource limits disable core dumping for process 76 (udevd).
Jan 04 07:53:25 p10bmc systemd-coredump[174]: Process 76 (udevd) of user 0 dumped core.
```
This error during boot was disabling all coredump generation and
collection on the system.
After a lot of digging, it was found that we were actually running 2
instances of udevd on the system. One started by this script, and
another by systemd-udevd.service. The one failing was the first one we
started. It's safe to assume that running 2 instances of udevd has
undefined behavior and something in more recent openbmc (or systemd) has
caused this fail to start.
Tested:
- Confirmed BMC still boots fine and coredumps now work
Change-Id: I3e4aaa82b18181f1bba62d76ff13af29437c9bb8
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Diffstat (limited to 'meta-phosphor/classes')
0 files changed, 0 insertions, 0 deletions