tree 35982d1b3a52c98836bb4fa8a22385023ede0ea6
parent 8711f98bdb372acbf85e7bec383ea6fbfcbafacc
author Andrew Geissler <geissonator@yahoo.com> 1540479430 -0500
committer Brad Bishop <bradleyb@fuzziesquirrel.com> 1540864141 +0000

Disable systemd-coredump from phosphor layer

Continue to hit two major issues with having coredumps
enabled in OpenBMC:

1. Filesystem space for coredumps

Systemd writes the core files to /var/lib/systemd/coredump/
This is a persistent filesystem so space is very limited.
There is currently no way to configure this location (would
need upstream work). Due to issue #2 below, when a single
application fails, it starts to cause other services to
coredump which results in the available space quickly
filling up. This can result in the UBI kernel driver
remounting the filesystem read-only.

2. CPU utilization

When an application fails, and causes a coredump, it is
restarted by systemd. The restart causes mapper to fire
up and introspect the restarted application. In parallel
the coredump is being generated and collected. These two
things heavily load the CPU. If this occurs during the
initial startup of the BMC, where lots of other services
are also starting and being introspected by mapper, then
those services can start hitting their systemd timeout
limit. This then results in core dumps being collected for
them and mapper instrospects being called on their restarts.
This causes a snowball affect where the system just
continues to restart services and collect core dumps.
The systemd restart policy can not account for these long
delays between restart (due to the CPU load) so the
limit is never hit within the time limit, resulting
in an infinite restart loop.

There is upstream work that could be done with systemd to
make the core dump function more embedded system friendly. This
would be a long term solution but may become a moot point
as performance improvmenents come in (c++ mapper), more
powerful CPU's are used, and more flash space is allocated
in future systems.

Personally, I've never used a core dump to debug an issue
and have dealt with the above issues multiple times so
I'm probably a bit biased. This could definitely be a
meta-ibm layer type change if others in the community
prefer this enabled as the default.

resolves openbmc/openbmc#3379

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