Add exclude of application core dumps in all directories.

[ryan-blakley]

Found a few sosreports here recently on a case that had 629 150ish mb application core dumps under /var/named/. This made the sosreport fully extracted 99GB in size. Would it be possible by default to exclude all files named core. and maybe a parameter to include them or no parameter? I personally don't see how having 629 app cores will help in anyway to work a case, all we would really need is the latest core file and that's it attached to the case.

Also potentially it could check /proc/sys/kernel/core_pattern, and if it's just set to core, and not abrt or systemd-coredump we exclude them. If it's set to just core it will drop a core name core. and in the working directory of the application. So we could hit this issue with multiple plugins depending on what the application/service's working directory is, and what directories sos is collecting.

[TurboTurtle]

Can you provide either the sos_logs/sos.log file from this report, or otherwise confirm which plugin collected those? And what version of sos did this? /var/named/ isn't explicitly called out by any plugins today.

More generally, I'd be open to some kind of filter here, just figuring out where to inject it is the question. There have been requests in the past to have sos collect crash dumps of various kinds, but I'd only feel safe doing so on a specific per-plugin basis where we allow list them, and this would be a good opportunity to facilitate both collecting and denying by core_pattern or similar.

[ryan-blakley]

Ack let me go through the sos.log and make sure I can share that here. I'll also see if I can track down what pulled them in.

Yeah I thought I'd throw it out as an idea, I had no clue what was the best way to achieve this. We're going to try and filter these files from the extraction point of view. But I felt we really don't need to be collecting them in general since it can bloat a report quickly.

[ryan-blakley]

So it's version 3.8 and it was the named plugin that created the files it looks like.

$ grep -i "var\/named" sos_logs/sos.log
2022-06-02 17:41:13,820 INFO: [plugin:named] adding forbidden path '/var/named/chroot/dev'
2022-06-02 17:41:13,820 INFO: [plugin:named] adding forbidden path '/var/named/chroot/proc'
2022-06-02 17:41:29,102 INFO: [plugin:named] collecting path '/var/named'

[TurboTurtle]

Wow, that's got some age to it.

But, I see where we're picking up /var/named/ from now, was a little buried. And I can confirm that we'll still pick this up in 4.5.6.

On the one hand, we could just add a global blacklist entry for files ending in core (or, I guess core(.[0-9])? since I believe the default is core.1, core.2, etc...?), but that'd present issues to purposefully collecting core files (which we don't have any plugins that do this intentionally today to my knowledge) in any plugin.

[ryan-blakley]

The default is to name them core. and it's dumped in the applications working directory if abrt or systemd-coredump isn't used. Generally abrt or systemd-coredump is the default for RHEL, but if neither are installed /proc/sys/kernel/core_pattern defaults to the above.

So I figured to not have to run the blacklist check on every file, the core_pattern file could be queried early on to check it's contents. If it contains any % symbols or white spaces we ignore the blacklist. If it doesn't contain any % symbols or white spaces, we can set the blacklist to whatever the content of the core_pattern file is plus the regex for the pid. Because technically you could enter any string into core_pattern and it would dump as a file named string..