On Fri, Sep 30, 2016 at 5:50 AM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > On Thu, Sep 15, 2016 at 08:52:03AM -0600, Chris Murphy wrote: >> On Thu, Sep 15, 2016 at 8:17 AM, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: >> > Hi, >> > >> > Something between F23 and F24 broke coredumpctl in Fedora. It's still >> > broken. Appears to be an SELinux bug. It's reported as [1]. I want >> > coredumpctl to be enabled by default in F26 as a F26 feature, but I can >> > hardly go ahead and propose that while it's still broken. It would be >> > great if the SELinux developers could look into the issue. systemd >> > developers have been responsive and already left several comments in >> > the bug, but I've failed to get the attention of SELinux folks thus >> > far. > > Hi, > > a bunch of patches which resulted from your report have now been merged > into systemd upsteam (https://github.com/systemd/systemd/commit/6740ec4a6), > which should, I hope, fix the issues you mentioned. > > You could try the git version, or wait a bit. The next release is being > prepared, and rawhide should have it within a few days. Those patches > should also be backported for F25 (F24?), but that will take longer. Awesome yes I'll try it once it appears in Rawhide, might be a few weeks. > >> I think that's only part of the problem. I regularly get: is not a >> core dump: File format not recognized > It was a problem with copying of uncompressed coredumps. > >> I asked about it on systemd list and there's no reply. And very often >> now I get this: More than one entry matches, ignoring rest. > Off-by-one in the condition check. > >> I get that message whether I specify by PID or by EXE. The man page >> example by path to executable says it'll dump the most recent core >> file, but it doesn't. I get the 'more than one entry matches' and it >> creates a 0 length file. I have entries going back to June, inevitably >> there are duplicates. There's also no command to clean things up. > That's the same as the first issue. > >> And my favorite: >> >> Refusing to dump core to tty. > We now check that the file is readable (if the core is stored externally > on the fs), or that the journal entry has the COREDUMP= field (if it > is stored internally in the journal). In both cases it'll report all > errors that can be detected without actually reading and decompressing > the data, and only check if output is connected to a tty after that. > >> OK fine, so lets use --output= and dump it to a file! > The error message now also suggests --output or shell redirection. > >> Cannot retrieve coredump from journal nor disk. >> Coredump retrieval failed: No such file or directory >> >> OK so it exists, but can't go to tty... oh wait you want it output to >> a file? No it doesn't exist. What? > I also added a bunch of log messages when the core is being _written_ > and core writing is disabled, or is being written truncated because of > the size limits. This could still use improvement, to report things > better when _reading_ the core, it's on the TODO list. > > Thanks for the report! Thanks for the followup. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
