Bug 1714243

The specific selection of filemasks from /var/log/sa directory is really redundantly strict.

Any objections in copying whole /var/log/sa/ directory content, up to 25MB by default, with newest-to-older files ordering (in case size limit hit)?

Plus leave there the calls for "sar -A .." and "sadf -x .." from line https://github.com/sosreport/sos/blob/master/sos/plugins/sar.py#L50 further.


That means, patch like:

@@ -26,20 +26,8 @@ class Sar(Plugin,):
     sa_size = 20
 
     def setup(self):
-        if self.get_option("all_sar"):
-            self.sa_size = 0
-
-        # Copy all sa??, sar??, sa??.* and sar??.* files, which will net
-        # compressed and uncompressed versions, typically.
-        for suffix in ('', '.*'):
-            self.add_copy_spec(
-                os.path.join(self.sa_path, "sa[0-3][0-9]" + suffix),
-                sizelimit=self.sa_size, tailit=False
-            )
-            self.add_copy_spec(
-                os.path.join(self.sa_path, "sar[0-3][0-9]" + suffix),
-                sizelimit=self.sa_size, tailit=False
-            )
+        self.add_copy_spec(self.sa_path,
+                           sizelimit=0 if self.get_option("all_sar") else None)
 
         try:
             dir_list = os.listdir(self.sa_path)

?

(sizelimit=None means default size limit, 25MB; sizelimit=0 means no limit)

Hello, here is a more detailed description:

https://access.redhat.com/support/cases/internal/#/case/02386877

<kfujii>

...

For example,

When saYYYYMMDD format sar files only are created in /var/log/sa/, sosreport does not try to include any sar info like /var/log/sa  and /sos_commands/sar.

sosreport  should need to handle saYYYYMMDD format sar files  corrctly as same as  saDD format sar files  (default formats sar files).

saYYYYMMDD format sar files are created when we change the history days to over 28 days in /etc/sysconfig/sysstat


#cat /etc/sysconfig/sysstat
       1  # sysstat-11.7.3 configuration file.
       2
       3  # How long to keep log files (in days).
       4  # If value is greater than 28, then use sadc's option -D to prevent older
       5  # data files from being overwritten. See sadc(8) and sysstat(5) manual pages.
       6  #HISTORY=28  <--- comment out
       7  HISTORY=366  <--- Add new history days ( over 28 days )

<kfujii/>

---
Regards,
Josef Kubin.
Software Maintenance Engineer
Red Hat Czech, s.r.o.

That is covered in my proposal, now in the linked PR :)

jkb promised OtherQE for 8.1

Hi,
could you pls. verify the bug against below build? Thanks in advance.


A yum repository for the build of sos-3.7-2.el8 (task 22574870) is available at:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.7/2.el8/

You can install the rpms locally by putting this .repo file in your /etc/yum.repos.d/ directory:

http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.7/2.el8/sos-3.7-2.el8.repo

RPMs and build logs can be found in the following locations:
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.7/2.el8/noarch/

The full list of available rpms is:
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.7/2.el8/noarch/sos-3.7-2.el8.src.rpm
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.7/2.el8/noarch/sos-3.7-2.el8.noarch.rpm
http://brew-task-repos.usersys.redhat.com/repos/official/sos/3.7/2.el8/noarch/sos-audit-3.7-2.el8.noarch.rpm

Build output will be available for the next 21 days.

Hi, I am back from PTO.

Thank you for the links, I just downloaded packages.

Tomorrow I'll test them.

---
Regards,
Josef Kubin.
Software Maintenance Engineer
Red Hat Czech, s.r.o.

Looks by my testing that saYYYYMMDD and sarYYYYMMDD files are now collected by sos-3.7-2.el8.noarch

There is diferecnce though.

For YYYYMMDD variant of files:
 * xml variant of sar is not collected.
 * human readable sar variant for every sa file without sar equivalent already created is not collected.

I assume that the xml and sar generation is not requirement of this bugzilla. Please correct me if I'm wrong.

FYI upstream discussion on the same (sar -A / sadf -X):

https://github.com/sosreport/sos/issues/1741

I'm testing it now ...

I can confirm, that var/log/sa/saYYYYMMDD are collected in sosreport now.
I'll be back soon.

---
Regards,
Josef Kubin.
Software Maintenance Engineer
Red Hat Czech, s.r.o.

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, 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/RHEA-2019:3640