[opensuse-factory] gnome-shell is ignored by systemd-coredump
![](https://seccdn.libravatar.org/avatar/f4fec499f3d1c17645b08fd2127f6b77.jpg?s=120&d=mm&r=g)
Hi list, So I'm suffering from g-s segfaults every so often, which sometimes result in putting user session or even whole system down (doesn't react to SysRq keys as well; yes, they are enabled). In order to provide useful bug report I'm supposed to provide at least a backtrace extracted from core dumps, right? It's so great to know we're already covered — core files are conveniently collected by systemd-coredump. Except, well, that's not the case for the gnome-shell: thanks to core size set to zero for this particular process (and its' parent gnome-session-binary; ), systemd-coredump refuses to dump its' core (see http://paste.opensuse.org/77024771). True, I am able to collect backtrace by manually attaching to gnome-shell by hand with gdb and actually telling it to show the backtrace; but honestly, this is tedious and g-s crashes much more often than I can afford attaching gdb again and again. In the meantime, googling the relevant parts of backtrace (https://bugzilla.opensuse.org/attachment.cgi?id=742663) revealed a twin brother of the crash of mine at https://retrace.fedoraproject.org/faf/reports/1729548/ (except version numbers: I've got 3.26 vs 3.24 in Fedora). It also implies core dumps of gnome-shell weren't disabled by upstream, but by openSUSE. Which poses the question: how can I have automated g-s core dumps back? And, for sake of curiosity, how and why were they even disabled at all? Thank you in advance. -- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/5b748275c3dbb1ceee18ed554486547d.jpg?s=120&d=mm&r=g)
On Sunday 2017-10-08 14:05, Andrei Dziahel wrote:
Which poses the question: how can I have automated g-s core dumps back? And, for sake of curiosity, how and why were they even disabled at all?
Does gnome-shell do suid games? Then sysctl fs.suid_dumpable Can gnome-shell write to the right directory? sysctl kernel.core_pattern Is gnome-shell not exceeding its core limits? ulimit -c and /proc/$$/limits -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/482b6c0369f4709de8faa6843cd6b347.jpg?s=120&d=mm&r=g)
On dimanche, 8 octobre 2017 19.38:10 h CEST Jan Engelhardt wrote:
On Sunday 2017-10-08 14:05, Andrei Dziahel wrote:
Which poses the question: how can I have automated g-s core dumps back? And, for sake of curiosity, how and why were they even disabled at all?
Does gnome-shell do suid games? Then sysctl fs.suid_dumpable Can gnome-shell write to the right directory? sysctl kernel.core_pattern Is gnome-shell not exceeding its core limits? ulimit -c and /proc/$$/limits
I'm also interested by make coredump great again. I've now since months none of the backtrace recorded in var/lib/systemd/ coredump (or some truncated). For example Sat 2017-10-07 10:53:45 CEST 1901 1502 1500 11 none /usr/bin/ baloo_file 1502 being me I've setup (as I can on my laptop) generous vars in /etc/systemd/coredump.conf [Coredump] Storage=external Compress=yes ProcessSizeMax=32G ExternalSizeMax=32G JournalSizeMax=16G MaxUse=32G KeepFree=2G So I can't understand why I don't get backtrace. I've now created a systemd-coredump@1502.service link as @0 exist but didn't find the right documentation for it. journalctl give some info Oct 08 12:29:46 qt-kt.labaroche.ioda.net systemd[1]: Requested transaction contradicts existing jobs: Transaction is destructive. Oct 08 12:29:46 qt-kt.labaroche.ioda.net systemd[1]: systemd-coredump.socket: Failed to queue service startup job (Maybe the service file is missing or not a non-template unit?): Transaction is de Oct 08 12:29:46 qt-kt.labaroche.ioda.net systemd[1]: systemd-coredump.socket: Unit entered failed state. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/f4fec499f3d1c17645b08fd2127f6b77.jpg?s=120&d=mm&r=g)
Hi 2017-10-08 20:38 GMT+03:00 Jan Engelhardt <jengelh@inai.de>:
On Sunday 2017-10-08 14:05, Andrei Dziahel wrote:
Which poses the question: how can I have automated g-s core dumps back? And, for sake of curiosity, how and why were they even disabled at all?
Does gnome-shell do suid games? Then sysctl fs.suid_dumpable
I don't know, does it? Also should it? fs.suid_dumpable = 0
Can gnome-shell write to the right directory? sysctl kernel.core_pattern Does it matter? It's dead, it shouldn't write anywhere; and it probably can't as it's run as regular user. kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e It is systemd-coredump writing cores, not defunct gnome-shell.
Is gnome-shell not exceeding its core limits? ulimit -c and /proc/$$/limits ulimit -c is 0, presumably inherited from gnome-session-binary re: proc/..limits: https://gist.github.com/develop7/8d75aa626fffec489947f6746100a436#file-gistf...
We also can see just above how systemd-coredump explicitly refuses to dump core because core size is 0. In before limits.conf: https://gist.github.com/develop7/8d75aa626fffec489947f6746100a436#file-gistf..., https://gist.github.com/develop7/8d75aa626fffec489947f6746100a436#file-limit... and https://gist.github.com/develop7/8d75aa626fffec489947f6746100a436#file-gistf... -- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Andrei Dziahel
-
Bruno Friedmann
-
Jan Engelhardt