Description of problem: Script ovirt-log-collector-analyzer fails on tar error. But it is related to scl PG10. Version-Release number of selected component (if applicable): ovirt-log-collector-analyzer-4.3.0-0.0.master.20180828120238.git316ba14.el7.noarch rhv-log-collector-analyzer-0.1.7-0.el7ev.noarch How reproducible: always Steps to Reproduce: 1. run ovirt-log-collector 2. add read permissions on created sosreport for postgres user 3. run analyzer with postgres user e.g.: $ su - postgres -c "cd /tmp; ovirt-log-collector-analyzer /tmp/sosreport-LogCollector-20181212110314.tar.xz" Actual results: Unpacking postgres data. This can take up to several minutes. tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors Expected results: no error, analyzer creates report Additional info: The main problem is in this command: /usr/share/ovirt-log-collector/analyzer/unpackAndPrepareDump.sh line 97 tar -Oxf "/tmp/tmp.PgmOSjb4Vj/unpacked_sosreport/sosreport-LogCollector-20181212100955/log-collector-data/postgresql-sosreport-system-ge-4-2018-12-12-qmkputf.tar.xz" "sosreport-system-ge-4-2018-12-12-qmkputf/sos_commands/postgresql/pgdump-scl-rh-postgresql95.tar" it fails on pg_dump version mismatch and so no tar file goes to piped tar command. I tested it on upgraded 4.2 -> 4.3 engine and also clean 4.3 d/s build.
Steps to Reproduce: 1. run ovirt-log-collector 2. add read permissions on created sosreport for postgres user 3. run analyzer with postgres user su - postgres -c "cd /tmp; rhv-log-collector-analyzer /tmp/sosreport-LogCollector-20190130135549.tar.xz" Results: Preparing environment: ====================== Temporary working directory is /tmp/tmp.04WrPttIEC Unpacking postgres data. This can take up to several minutes. tar: This does not look like a tar archive tar: Exiting with failure status due to previous errors rm: cannot remove ‘/tmp/ovirt-log-collector-analyzer-hosts’: Operation not permitted Expected results: No errors, report created Tested in: rhv-log-collector-analyzer-0.2.3-0.el7ev.noarch ovirt-log-collector-4.3.0-1.el7ev.noarch
(In reply to Ivana Saranova from comment #4) > Steps to Reproduce: > 1. run ovirt-log-collector > 2. add read permissions on created sosreport for postgres user > 3. run analyzer with postgres user > > su - postgres -c "cd /tmp; rhv-log-collector-analyzer > /tmp/sosreport-LogCollector-20190130135549.tar.xz" > > > Results: > > Preparing environment: > ====================== > Temporary working directory is /tmp/tmp.04WrPttIEC > Unpacking postgres data. This can take up to several minutes. > tar: This does not look like a tar archive > tar: Exiting with failure status due to previous errors > rm: cannot remove ‘/tmp/ovirt-log-collector-analyzer-hosts’: Operation not > permitted > Could you please check the permissions for /tmp/ovirt-log-collector-analyzer-hosts? postgres user doesn't have the permission to remove it. I would suggest removing the dir and trying again run the tool as postgres. Could you please also share the sosreport? Thanks!
Not blocking ovirt-4.3.0 on this. Moving to 4.3.1.
No, even with ovirt-log-collector --log-size=0 analyzer still doesn't recognize the sos report as tar archive.
(In reply to Ivana Saranova from comment #10) > No, even with ovirt-log-collector --log-size=0 analyzer still doesn't > recognize the sos report as tar archive. Could you please share the test machine?
Moving to 4.3.2 not being identified as blocker for 4.3.1.
Please retarget if fix is not in compose 4.3.3 GA or move to ON_QA.
Moving needinfo to Douglas.
To be tested with sos shipped within RHEL 7.7
(In reply to Sandro Bonazzola from comment #19) > To be tested with sos shipped within RHEL 7.7 It seems it is not only sos problem. We have already tested it and sos now generates PG10 dump but the analyzer can't consume it. It tries to get only PG95 dump. So we still get error 'tar: This does not look like a tar archive' See /usr/share/rhv-log-collector-analyzer/analyzer/unpackAndPrepareDump.sh 84: PG_DUMP_TAR=$(tar tf "$TAR_WITH_POSTGRES_SOSREPORT" | grep "pgdump-scl-rh-postgresql95.tar") || : Tested with rhv-log-collector-analyzer-0.2.4-0.el7ev.noarch and sos-3.7-5.el7.noarch
Hi there, (In reply to Lucie Leistnerova from comment #20) > (In reply to Sandro Bonazzola from comment #19) > > To be tested with sos shipped within RHEL 7.7 > > It seems it is not only sos problem. We have already tested it and sos now > generates PG10 dump but the analyzer can't consume it. It tries to get only > PG95 dump. > So we still get error 'tar: This does not look like a tar archive' > > See > /usr/share/rhv-log-collector-analyzer/analyzer/unpackAndPrepareDump.sh > > 84: PG_DUMP_TAR=$(tar tf "$TAR_WITH_POSTGRES_SOSREPORT" | grep > "pgdump-scl-rh-postgresql95.tar") || : > > Tested with rhv-log-collector-analyzer-0.2.4-0.el7ev.noarch and > sos-3.7-5.el7.noarch What's the content for pgdump-scl-rh-postgresql95.tar ? What it generated in a environment with recent sosreport? Can I have access to env?
(In reply to Douglas Schilling Landgraf from comment #21) > Hi there, > > (In reply to Lucie Leistnerova from comment #20) > > (In reply to Sandro Bonazzola from comment #19) > > > To be tested with sos shipped within RHEL 7.7 > > > > It seems it is not only sos problem. We have already tested it and sos now > > generates PG10 dump but the analyzer can't consume it. It tries to get only > > PG95 dump. > > So we still get error 'tar: This does not look like a tar archive' > > > > See > > /usr/share/rhv-log-collector-analyzer/analyzer/unpackAndPrepareDump.sh > > > > 84: PG_DUMP_TAR=$(tar tf "$TAR_WITH_POSTGRES_SOSREPORT" | grep > > "pgdump-scl-rh-postgresql95.tar") || : > > > > Tested with rhv-log-collector-analyzer-0.2.4-0.el7ev.noarch and > > sos-3.7-5.el7.noarch > > What's the content for pgdump-scl-rh-postgresql95.tar ? What it generated in > a environment with recent sosreport? > Can I have access to env? Replying to myself, it seems we should patch analyzer to accept any postgresql version generated.
As of now, rhv-log-collector-analyzer is not intended to work with tar archives, therefore the functionality was tested with running only the rhv-log-collector-analyzer and checking the generated html file. Steps: 1) Run `rhv-log-collector-analyzer` 2) Check that analyzer did not end with error and html report file is correct Result: Analyzer was successful and html report file is correct. Verified in: rhv-log-collector-analyzer-0.2.8-0.el7ev.noarch ovirt-engine-4.3.6-0.1.el7.noarch
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/RHBA-2019:3012