Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
configuration.
How reproducible:
Allways
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
Actual results:
Only one (tailed) or few logs in sosreport
Expected results:
All (tailed eventually) log-files in sosreport.
Additional info:
Proposed solution is to list log-files individually, not as one copy-set.
Upstream PR: https://github.com/sosreport/sos/pull/2445
> 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
> debugging?)
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.
Merging to legacy-3.9 branch
https://github.com/sosreport/sos/pull/2476
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?
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.
https://access.redhat.com/errata/RHBA-2021:2804