Description of problem: sosreport usually doesn't collect all sssd log.
The issue is that SSSD creates individual log files for its
components. To be able to track the issue we need all of them.
With one wildcard copy set we usually get just one truncated
log file and this is not very useful for solving issues. We
need to track the request accross logs to understand the
problem. Also log file names are specific for paricular
Steps to Reproduce:
1. in /var/log/sssd create log files that are bigger than sosreport size limit
2. run sosreport
3. check the archive - log files are not collected
Only one (tailed) or few logs in sosreport
All (tailed eventually) log-files in sosreport.
Proposed solution is to list log-files individually, not as one copy-set.
Upstream PR: https://github.com/sosreport/sos/pull/2445
not sure if https://github.com/sosreport/sos/pull/2444 is also worth to backport for RHEL7? (cf RHEL8 bz1940502 that requires both PRs)
> Pawel created one set to add the files from sss/mc (memory cache). But those files are binary blobs (big enough to go over default limits) and tailing them doesn't make much sense.
> is binary file also "tailed"?
Yes, by default any file over 25MB is tailed on this limit. There is (a command line option and) the option sizelimit of the add_copy_spec method to change this, where sizelimit=0 means no limit. But:
- be careful to use sizelimit=0, as if the to-be-collected file can be arbitrarily huge, sosreport will generate arbitrarily huge tarball (in arbitrarily huge time..)
- the sizelimit is applied to *each* file or pattern in the list. While I think our aim is to:
- collect whole memory cache (or no cache? is it valuable for some debugging?)
- collect limited amount of logs
So we should have two add_copy_specs, I guess? One for just logs, one for the memory cache (or one jst for logs without memory cache?).
Is somebody able to provide filepatterns / globs for those?
(In reply to Pavel Moravec from comment #4)
> While I think our aim is to:
> - collect whole memory cache (or no cache? is it valuable for some
Right, we need either whole cache or nothing, truncates doesn't make sense.
With default settings total size of all caches is about 25mb in total.
Vast majority of users never change this setting.
I think that's ok to either add cache files one by one or use 'sizelimit=50mb'.
(In reply to Alexey Tikhonov from comment #5)
> With default settings total size of all caches is about 25mb in total.
JFTR: I mean SSSD settings here.
I prepared PR which adds cache files one by one:
If it is possible it would be good to have all 3 PRs included in RHEL7.
In the worst case scenario must-have one is: https://github.com/sosreport/sos/pull/2445
At the moment all 3 of SSSD related PRs has been merged upstream .
Merging to legacy-3.9 branch
Depending on merge date it should be possible to release to next z-stream batch (Tue 2021-06-08)
Pawel i am preparing all 3 PRs into next batch z-stream, will you be able to test applied changes and role as OtherQA when candidate package will be available or do you know who may serve as OtherQA?
Hi Jan, I love to help with testing and verification. If this will be about downloading your z-stream build candidate package and manual verification that it perform as planned?
Hi Pawel, that is exactly what we want, i will post here link for candidate when it will be ready.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (sos bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.