commit | 6863fe514b7d8cea80b36ffe0e866cde0df7f137 | [log] [tgz] |
---|---|---|
author | Andrew Geissler <geissonator@yahoo.com> | Thu Oct 25 09:57:10 2018 -0500 |
committer | Brad Bishop <bradleyb@fuzziesquirrel.com> | Mon Oct 29 21:59:34 2018 -0400 |
tree | 8972d2ef89ae74cf26e2718982093c6f59f64dea | |
parent | 3bb26b9d272d78a2378e5535616cfde6f12ef4ea [diff] |
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>
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.
sudo apt-get install -y git build-essential libsdl1.2-dev texinfo gawk chrpath diffstat
sudo dnf install -y git patch diffstat texinfo chrpath SDL-devel bitbake rpcgen sudo dnf groupinstall "C Development Tools and Libraries"
git clone git@github.com:openbmc/openbmc.git cd openbmc
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
Machine | TEMPLATECONF |
---|---|
Palmetto | meta-ibm/meta-palmetto/conf |
Zaius | meta-ingrasys/meta-zaius/conf |
Witherspoon | meta-ibm/meta-witherspoon/conf |
Romulus | meta-ibm/meta-romulus/conf |
As an example target Palmetto
export TEMPLATECONF=meta-ibm/meta-palmetto/conf
. openbmc-env bitbake obmc-phosphor-image
Additional details can be found in the docs repository.
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.
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.
Issues are managed on GitHub. It is recommended you search through the issues before opening a new one.
Feature List
Features In Progress
Features Requested but need help
Dive deeper in to OpenBMC by opening the docs repository.