** Description changed: Currently, `$ sysctl kernel.core_pattern` gives `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P` - This should be considered a bug, since a minimal version of ubuntu or - even debian, and more notoriously when run from containers, this will - just error out, with no core dump being produced, due to the absence of - apport. Adding to the problem, is with container where you can't just - change it per container, and should be changed from the host. I think - using apport (a non essential package) as a default without thought as - to it's absence is not robust design. + This should be considered a bug, since a minimal version of ubuntu + (server, core etc) and more notoriously when run from containers, this + will just error out, with no core dump being produced, due to the + absence of apport. Adding to the problem, is with container where you + can't just change it per container, and should be changed from the host. + I think using apport (a non essential package) as a default without + thought as to it's absence is not robust design. There are multiple options to deal with this: - 1. Drop apport as default and switch to a simple file in either /var/crash (this requires creating /var/crash as a part of the installation), or /tmp - 2. Switch to systemd-coredump, and default to it, since it already does this very well and provides "coredumpctl" which is much nicer to work with. systemd-coredump also is a part of the systemd suite of utils and doesn't pull in a larger dependency as apport -- which to date, isn't as robust (I still have "core" files being left all over the place by apport, mostly in my home folder). This also has a nice advantage of unifying the OSS community in terms of coredump handler. + 1. Drop apport as default and switch to a simple file in either /var/crash (this requires creating /var/crash as a part of the installation as it's currently created by apport), or /tmp + 2. Switch to systemd-coredump, and default to it, since it already does this very well and provides "coredumpctl" which is much nicer to work with. systemd-coredump also is a part of the systemd suite of utils and doesn't pull in a larger dependency as apport -- which to date, isn't as robust (I still have "core" files being left all over the place by apport, mostly in my home folder). This also has a nice advantage of unifying the OSS community in terms of coredump handler. 3. Employ a tiny helper script, as the default core dump handler, which looks for specified programs such as "apport", "abrt", systemd-coredump" and pipes to them, or pipes it to /var/crash, or /tmp during it's absence. + + And add a sysctl.d default rule here, or more cleanly a separate package + that does exactly this on option 3. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: procps 2:3.3.15-2ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu13.1 Architecture: amd64 CurrentDesktop: GNOME Date: Sat Jan 26 20:33:55 2019 InstallationDate: Installed on 2019-01-01 (25 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) SourcePackage: procps UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.apport.crashdb.conf: [modified] mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1813403 Title: Better kernel core dump defaults Status in procps package in Ubuntu: New Bug description: Currently, `$ sysctl kernel.core_pattern` gives `kernel.core_pattern = |/usr/share/apport/apport %p %s %c %d %P` This should be considered a bug, since a minimal version of ubuntu (server, core etc) and more notoriously when run from containers, this will just error out, with no core dump being produced, due to the absence of apport. Adding to the problem, is with container where you can't just change it per container, and should be changed from the host. I think using apport (a non essential package) as a default without thought as to it's absence is not robust design. There are multiple options to deal with this: 1. Drop apport as default and switch to a simple file in either /var/crash (this requires creating /var/crash as a part of the installation as it's currently created by apport), or /tmp 2. Switch to systemd-coredump, and default to it, since it already does this very well and provides "coredumpctl" which is much nicer to work with. systemd-coredump also is a part of the systemd suite of utils and doesn't pull in a larger dependency as apport -- which to date, isn't as robust (I still have "core" files being left all over the place by apport, mostly in my home folder). This also has a nice advantage of unifying the OSS community in terms of coredump handler. 3. Employ a tiny helper script, as the default core dump handler, which looks for specified programs such as "apport", "abrt", systemd-coredump" and pipes to them, or pipes it to /var/crash, or /tmp during it's absence. And add a sysctl.d default rule here, or more cleanly a separate package that does exactly this on option 3. ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: procps 2:3.3.15-2ubuntu1 ProcVersionSignature: Ubuntu 4.18.0-13.14-generic 4.18.17 Uname: Linux 4.18.0-13-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.10-0ubuntu13.1 Architecture: amd64 CurrentDesktop: GNOME Date: Sat Jan 26 20:33:55 2019 InstallationDate: Installed on 2019-01-01 (25 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) SourcePackage: procps UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.apport.crashdb.conf: [modified] mtime.conffile..etc.apport.crashdb.conf: 2019-01-15T04:51:59.517661 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1813403/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
