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.
Bug 1807397 - abrt-harvest-vmcore:252:harvest_vmcore:TypeError: delete_and_close() takes exactly 2 arguments (1 given)
Summary: abrt-harvest-vmcore:252:harvest_vmcore:TypeError: delete_and_close() takes ex...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: abrt
Version: 7.7
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: ekulik
QA Contact: Martin Kyral
URL:
Whiteboard:
Depends On:
Blocks: 1809949
TreeView+ depends on / blocked
 
Reported: 2020-02-26 09:44 UTC by jtougne
Modified: 2020-09-29 19:53 UTC (History)
3 users (show)

Fixed In Version: abrt-2.1.11-58.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1809949 (view as bug list)
Environment:
Last Closed: 2020-09-29 19:53:13 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
logspart1 (14.23 MB, application/x-xz)
2020-02-26 09:44 UTC, jtougne 		no flags Details
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:3912 0 None None None 2020-09-29 19:53:24 UTC

Description jtougne 2020-02-26 09:44:58 UTC 
Created attachment 1665895 [details]
logspart1

Description of problem:
Hi,
We run RHEL7.7,
abrt-x86_64 2.1.11-55-el7.

abrt-cli list seems to mix up older existing crash reports (time and directory not matching)

See, pay attention to this:
time:
Directory:

[root@hostname ~]# abrt-cli list
id 03116fc3ab8a3572fb9483aee2873ce4e663f172
reason: abrt-harvest-vmcore:252:harvest_vmcore:TypeError: delete_and_close() takes exactly 2 arguments (1 given)
time: Tue 25 Feb 2020 09:58:41 AM CET
cmdline: /usr/bin/python /usr/sbin/abrt-harvest-vmcore
package: abrt-addon-vmcore-2.1.11-55.el7
uid: 0 (root)
count: 1
Directory: /var/spool/abrt/Python-2020-02-25-09:58:41-3915
Run 'abrt-cli report /var/spool/abrt/Python-2020-02-25-09:58:41-3915' for creating a case in Red Hat Customer Portal

id 91691908307fed583e0186a30c243350658400ca
time: Tue 25 Feb 2020 09:57:28 AM CET
uid: 0
Directory: /var/spool/abrt/vmcore-127.0.0.1-2019-04-21-01:07:01.new
Run 'abrt-cli report /var/spool/abrt/vmcore-127.0.0.1-**2019-04-21-**01:07:01.new' for creating a case in Red Hat Customer Portal

The Autoreporting feature is disabled. Please consider enabling it by issuing
'abrt-auto-reporting enabled' as a user with root privileges
[root@hostame ~]# date
Tue Feb 25 10:45:26 CET 2020

I have verified, the file in question in /var/crash is actually really from 2019, I could see in the vmcore-dmesg some references to old kernel. Also, I did a ls -lrta of the folder and it all indicates 2019.

FYI, it seems that the issue is related to the presence of these files:

[root@hostname 127.0.0.1-2019-04-21-01:07:01]# pwd
/var/crash/127.0.0.1-2019-04-21-01:07:01
[root@hostname 127.0.0.1-2019-04-21-01:07:01]# ls -lrta
total 3801144
-rw-r--r--. 1 root root 1062268 Apr 21 2019 vmcore-dmesg.txt
-rw-------. 1 root root 3891301027 Apr 21 2019 vmcoreBKP25022020
drwxr-xr-x. 3 root root 43 Feb 25 11:36 ..
drwxr-xr-x. 2 root root 55 Feb 25 11:37 .
[root@hostname 127.0.0.1-2019-04-21-01:07:01]# date
Tue Feb 25 16:31:24 CET 2020

FYI, it appears that there is something wrong with that vmcore file. It was named vmcore, but I can not copy it, I cannot download it. I could rename it from vmcore to this vmcoreBKP25022020.

[root@hostname 127.0.0.1-2019-04-21-01:07:01]# lsattr vmcoreBKP25022020
lsattr: Operation not permitted While reading flags on vmcoreBKP25022020
[root@hostname 127.0.0.1-2019-04-21-01:07:01]# ls -lrta vmcoreBKP25022020
-rw-------. 1 root root 3891301027 Apr 21 2019 vmcoreBKP25022020
[root@hostname 127.0.0.1-2019-04-21-01:07:01]# date
Tue Feb 25 16:34:00 CET 2020

If you need the files abrt created, it's in Red Hat support case 02542116 (25Feb2020ch-sw01-i54x-06.zip)

Cheers.
Comment 5 jtougne 2020-02-26 13:35:56 UTC 
Hi
FYI I could not access the file because of this process: (MCAffee): isecptd

After stopping isecespd.service, the file was still not accessible and I could not even copy it.

After stopping isecptd, the file became accessible and I could finally copy it:
systemctl stop isectpd

See, the file is copied in /tmp:

ls -lrta /tmp/vmcoreBKP25022020
-rw-------. 1 root root 3891301027 Apr 21  2019 /tmp/vmcoreBKP25022020

The original file in /var/crash:
[root@ch-sw01-i54x-06 127.0.0.1-2019-04-21-01:07:01]# du -sh *
3.7G    vmcoreBKP25022020
1.1M    vmcore-dmesg.txt

Cheers,
Comment 6 ekulik 2020-02-26 14:08:37 UTC 
There’s a bit too much noise in the report. Is the problem that ABRT names the directories after vmcore files, but the time of occurence is the current moment?
Comment 7 jtougne 2020-02-26 14:13:59 UTC 
Hi,
See: 
time:
Directory:

time: Tue 25 Feb 2020 09:57:28 AM CET
...
Directory: /var/spool/abrt/vmcore-127.0.0.1-2019-04-21-01:07:01.new

That's the problem. It looks as if it's recent (2020) but the actual vmcore is from 2019.
Comment 8 ekulik 2020-02-26 14:23:10 UTC 
Well, the host and date bits in the name of the vmcore is just a string. The ABRT problem directories are dated to when they are created, not to arbitrary points in time as referred to by the file name.
Comment 9 ekulik 2020-02-26 14:26:35 UTC 
What benefit is there to inform the user of *newly found* crashes and have them date to last year?
Comment 10 jtougne 2020-02-26 15:44:59 UTC 
Hi,
I do not understand what you are trying to say. All I can say that it is confusing for the user this situation, and it appears there is a recent abrt entry but its in fact an old one.
Someone could wonder why abrt tool "could have" (I don't know what it is doing) picked a very old entry and present it as new.

Maybe its something like if it runs after a /var/crash already exists it gets confused...?


also note the ".new" in /var/spool/abrt/vmcore-127.0.0.1-2019-04-21-01:07:01.new.

Why the tool went to /var/crash... to pick a very old vmcore and tag it as new?

Clearly I don't understand the tool as well as you, but the situation currently is not normal.

Cheers,
Comment 11 ekulik 2020-02-26 15:52:11 UTC 
The situation is quite simple: ABRT finds a new vmcore file under /var/crash, creates a new problem for it and that’s it. What’s not normal is that you have a vmcore file from last year, so ABRT cannot do anything else but just accept it as new, because it would otherwise have been deleted already.

03116fc3ab8a3572fb9483aee2873ce4e663f172 is very likely preventing ABRT from doing its job properly in this case.
Comment 12 ekulik 2020-02-26 15:54:52 UTC 
https://github.com/abrt/abrt/commit/179843d3800f4dd66b143968792a81668a7b172a should fix that.
Comment 18 errata-xmlrpc 2020-09-29 19:53:13 UTC 
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 (abrt 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-2020:3912
Note You need to log in before you can comment on or make changes to this bug.