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. > 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! Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
