Bug 1807397
| Summary: | abrt-harvest-vmcore:252:harvest_vmcore:TypeError: delete_and_close() takes exactly 2 arguments (1 given) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | jtougne | ||||
| Component: | abrt | Assignee: | ekulik | ||||
| Status: | CLOSED ERRATA | QA Contact: | Martin Kyral <mkyral> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 7.7 | CC: | ekulik, mkyral, msuchy | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | abrt-2.1.11-58.el7 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1809949 (view as bug list) | Environment: | |||||
| Last Closed: | 2020-09-29 19:53:13 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1809949 | ||||||
| Attachments: |
|
||||||
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, 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? 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. 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. What benefit is there to inform the user of *newly found* crashes and have them date to last year? 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, 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. 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 |
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.