diff options
| author | Andrew Geissler <geissonator@yahoo.com> | 2018-10-25 09:57:10 -0500 |
|---|---|---|
| committer | Brad Bishop <bradleyb@fuzziesquirrel.com> | 2018-10-29 21:59:34 -0400 |
| commit | 6863fe514b7d8cea80b36ffe0e866cde0df7f137 (patch) | |
| tree | 8972d2ef89ae74cf26e2718982093c6f59f64dea /meta-phosphor/recipes-core | |
| parent | 3bb26b9d272d78a2378e5535616cfde6f12ef4ea (diff) | |
| download | talos-openbmc-6863fe514b7d8cea80b36ffe0e866cde0df7f137.tar.gz talos-openbmc-6863fe514b7d8cea80b36ffe0e866cde0df7f137.zip | |
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
(From meta-phosphor rev: dde999f1076f571a1760c9e5e536e63796749e57)
Change-Id: Ib229d8bf58aa075926fd302a0139a042d069f446
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Signed-off-by: Brad Bishop <bradleyb@fuzziesquirrel.com>
Diffstat (limited to 'meta-phosphor/recipes-core')
| -rw-r--r-- | meta-phosphor/recipes-core/systemd/systemd_%.bbappend | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/meta-phosphor/recipes-core/systemd/systemd_%.bbappend b/meta-phosphor/recipes-core/systemd/systemd_%.bbappend index bc568cd48..7baf1466d 100644 --- a/meta-phosphor/recipes-core/systemd/systemd_%.bbappend +++ b/meta-phosphor/recipes-core/systemd/systemd_%.bbappend @@ -1,7 +1,7 @@ FILES_${PN}-catalog-extralocales = \ "${exec_prefix}/lib/systemd/catalog/*.*.catalog" PACKAGES =+ "${PN}-catalog-extralocales" -PACKAGECONFIG_append = " networkd coredump" +PACKAGECONFIG_append = " networkd" PACKAGECONFIG_remove = "machined hibernate ldconfig binfmt backlight localed \ quotacheck kdbus ima smack polkit logind bootchart utmp \ manpages" |
