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>
1 file changed
tree: 8972d2ef89ae74cf26e2718982093c6f59f64dea
  1. meta-arm/
  2. meta-aspeed/
  3. meta-evb/
  4. meta-facebook/
  5. meta-google/
  6. meta-hxt/
  7. meta-ibm/
  8. meta-ingrasys/
  9. meta-intel/
  10. meta-inventec/
  11. meta-mellanox/
  12. meta-nuvoton/
  13. meta-openembedded/
  14. meta-openpower/
  15. meta-phosphor/
  16. meta-portwell/
  17. meta-qualcomm/
  18. meta-quanta/
  19. meta-raspberrypi/
  20. meta-security/
  21. meta-x86/
  22. meta-xilinx/
  23. poky/
  24. .gitignore
  25. .gitreview
  26. .templateconf
  28. openbmc-env
  29. README.md
  30. setup


Build Status

The OpenBMC project can be described as a Linux distribution for embedded devices that have a BMC; typically, but not limited to, things like servers, top of rack switches or RAID appliances. The OpenBMC stack uses technologies such as Yocto, OpenEmbedded, systemd, and D-Bus to allow easy customization for your server platform.

Setting up your OpenBMC project

1) Prerequisite

  • Ubuntu 14.04
sudo apt-get install -y git build-essential libsdl1.2-dev texinfo gawk chrpath diffstat
  • Fedora 28
sudo dnf install -y git patch diffstat texinfo chrpath SDL-devel bitbake rpcgen
sudo dnf groupinstall "C Development Tools and Libraries"

2) Download the source

git clone git@github.com:openbmc/openbmc.git
cd openbmc

3) Target your hardware

Any build requires an environment variable known as TEMPLATECONF to be set to a hardware target. You can see all of the known targets with find meta-* -name local.conf.sample. Choose the hardware target and then move to the next step. Additional examples can be found in the OpenBMC Cheatsheet


As an example target Palmetto

export TEMPLATECONF=meta-ibm/meta-palmetto/conf

4) Build

. openbmc-env
bitbake obmc-phosphor-image

Additional details can be found in the docs repository.

Build Validation and Testing

Commits submitted by members of the OpenBMC GitHub community are compiled and tested via our Jenkins server. Commits are run through two levels of testing. At the repository level the makefile make check directive is run. At the system level, the commit is built into a firmware image and run with an arm-softmmu QEMU model against a barrage of CI tests.

Commits submitted by non-members do not automatically proceed through CI testing. After visual inspection of the commit, a CI run can be manually performed by the reviewer.

Automated testing against the QEMU model along with supported systems are performed. The OpenBMC project uses the Robot Framework for all automation. Our complete test repository can be found here.

Submitting Patches

Support of additional hardware and software packages is always welcome. Please follow the contributing guidelines when making a submission. It is expected that contributions contain test cases.

Bug Reporting

Issues are managed on GitHub. It is recommended you search through the issues before opening a new one.

Features of OpenBMC

Feature List

  • REST Management
  • IPMI
  • SSH based SOL
  • Power and Cooling Management
  • Event Logs
  • Zeroconf discoverable
  • Sensors
  • Inventory
  • LED Management
  • Host Watchdog
  • Simulation
  • Code Update Support for multiple BMC/BIOS images
  • POWER On Chip Controller (OCC) Support

Features In Progress

  • Full IPMI 2.0 Compliance with DCMI
  • Verified Boot
  • HTML5 Java Script Web User Interface

Features Requested but need help

  • OpenCompute Redfish Compliance
  • OpenBMC performance monitoring
  • cgroup user management and policies
  • Remote KVM
  • Remote USB
  • OpenStack Ironic Integration
  • QEMU enhancements

Finding out more

Dive deeper in to OpenBMC by opening the docs repository.