| commit | 4cb0799f166f5a740bdd239d4cd7a062118821a0 | [log] [tgz] |
|---|---|---|
| author | Chirag Sharma <chirshar@in.ibm.com> | Mon May 09 04:37:22 2022 -0500 |
| committer | Marri Devender Rao <devenrao@in.ibm.com> | Fri Jan 20 04:16:57 2023 -0600 |
| tree | bc57a0369178f93407d93e9f4a2eb2e646910ba6 | |
| parent | 3598158b90a69177f25f2ff6aab05c385c8fc987 [diff] |
dump: failure as open file handles are not closed Dump manager adds watch using inotify_add_watch when dump generation starts and closes the fd(file handle) returned by the inotify_add_watch after dump generation is completed. Due to logic error, the fd is not closed, due to that the application exhausts the fd count over time when a lot of dumps are generated and it fails eventually. The dump manager maintains stl::map of the path and watch objects for newly created dumps so that when dump generation is completed it can create D-Bus objects for the dumps. When adding new entry to the stl::map dump directory is passed and when clearing the entry the file path of dump file is pased due to this entry from stl::map is not cleard and so is the watch object. Tested: Post changes able to trigger 200+ dumps without any issue. Verfied the open fd for the dump manager process before and after dump genration and ensured that fd's are not incread. before dump generation root@p10bmc:~# ls -la /proc/4890/fd dr-x------ 2 root root 0 Jan 20 10:03 . dr-xr-xr-x 8 root root 0 Jan 20 10:03 .. lr-x------ 1 root root 64 Jan 20 10:04 0 -> /dev/null lrwx------ 1 root root 64 Jan 20 10:04 1 -> socket:[35868] lrwx------ 1 root root 64 Jan 20 10:04 2 -> socket:[35868] lrwx------ 1 root root 64 Jan 20 10:03 3 -> socket:[35873] lrwx------ 1 root root 64 Jan 20 10:04 4 -> anon_inode:[eventpoll] lr-x------ 1 root root 64 Jan 20 10:04 5 -> anon_inode:inotify lrwx------ 1 root root 64 Jan 20 10:04 6 -> anon_inode:[timerfd] after dump generation root@p10bmc:~# ls -la /proc/4890/fd dr-x------ 2 root root 0 Jan 20 10:03 . dr-xr-xr-x 8 root root 0 Jan 20 10:03 .. lr-x------ 1 root root 64 Jan 20 10:04 0 -> /dev/null lrwx------ 1 root root 64 Jan 20 10:04 1 -> socket:[35868] lrwx------ 1 root root 64 Jan 20 10:04 2 -> socket:[35868] lrwx------ 1 root root 64 Jan 20 10:03 3 -> socket:[35873] lrwx------ 1 root root 64 Jan 20 10:04 4 -> anon_inode:[eventpoll] lr-x------ 1 root root 64 Jan 20 10:04 5 -> anon_inode:inotify lrwx------ 1 root root 64 Jan 20 10:04 6 -> anon_inode:[timerfd] lrwx------ 1 root root 64 Jan 20 10:05 7 -> socket:[35916] Signed-off-by: Chirag Sharma <chirshar@in.ibm.com> Change-Id: I67c704719e9991fdff478891f9dc72045fb0e9e1
Phosphor Debug Collector provides mechanisms to collect various log files and system parameters. Used to troubleshoot problems in OpenBMC based systems.
One such mechanism is dreport, a script that collects debug data and packages it into an archive file.
To build this package with meson, do the following steps:
1. meson builddir
2. ninja -C builddir
To clean the built files run ninja -C builddir clean.
Tests can be run in the CI docker container, refer local-ci-build
or with an OpenBMC x86 sdk(see below for x86 steps).
meson -Dtests=enabled build ninja -C build test