Bug 2171200
| Summary: | Entry in /usr/lib/systemd/system/abrtd.service causes systemd to show livesys.service error even when livesys disabled/removed | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Dodson <jwadodson> |
| Component: | abrt | Assignee: | Michal Srb <msrb> |
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 39 | CC: | abrt-devel-list, abrt-sig, mgrabovs, michal.toman, msrb |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-11-27 21:05:02 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: | |||
Still a problem in FC38 I commented this line out of /etc/systemd/system/multi-user.target.wants/abrtd.service After=livesys.service to work around the problem, it's back in the version of that file dated 2023 Jun 30 10:00 abrt-2.17.1-1.fc38.x86_64 python3-abrt-2.17.1-1.fc38.x86_64 ? Can someone PLEASE fix it or comment it out in the distributed version? Can we make it conditional? Thank you for the bug report. The fix will be included in the next abrt release ;) Any idea when that will be? Oh & also when /var/tmp/abrt will not be "recreated" (if it's now unused)? If removed /var/tmp/abrt is recreated each night following a systemd restart. /etc/systemd/system/multi-user.target.wants/abrtd.service
Still has,
After=livesys.service
So still broken & same error in FC39
abrt-2.17.1-3.fc39.x86_64
systemd.x86_64 254.7-1.fc39
python3-abrt-2.17.1-3.fc39.x86_64
Also /var/tmp/abrt is still recreated if removed. As at Sat 16 Dec 2023 11:04:33 AEDT abrt.x86_64 2.17.1-3.fc39 @fedora python3-abrt.x86_64 2.17.1-3.fc39 @fedora systemd.x86_64 254.7-1.fc39 @updates I see that there is now a 2.17.5 release of abrt. Any idea when at least 2.17.2 will make it into a current fedora release? eg. FC39? Still... abrt.x86_64 2.17.1-3.fc39 When oh when... & when will /var/tmp/abrt not be created for no reason? We are now at 2.17.6-1 with FC40 is the fix in that? It seems so. & /var/tmp/abrt is not created by default? If so we can close this? Thanks This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26. Fedora Linux 39 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Entry in /usr/lib/systemd/system/abrtd.service causes systemd to show livesys.service error even when livesys disabled/removed. # livesys.service has been added because of live distributions mounting tmpfs # to /var/tmp after abrtd.service was started which was hiding /var/tmp/abrt # which was created before the mount to tmpfs happened After=livesys.service Version-Release number of selected component (if applicable): abrt-2.15.1-6.fc37.x86_64 (This is probably really a systemd problem, 251.11-2.fc37) How reproducible: Always unless that line is commented out. Steps to Reproduce: 1. Remove all trace of livesys after installation (otherwise it generates other "messages" by just being there & it should be removed right?). 2. systemctl -all |grep livesys livesys.service not-found inactive dead livesys.service 3. The "problem" is also manifested by Actual results: Uninstalled systemd objects should not give an error status Expected results: The ability to run systemctl -all & see no errors/services in error states, when you've ironed out all the mysteries & unnecessary components. Additional info: It would seem that systemd needs a better system of ordering or checking for unused/installed components that require ordering or "Conflicts=" (which also generate a similar effect. Or merely "noting silently that an uninstalled/non-conflicting package does not need to be considered in it's logic" - but that's probably a recipe for more subtle bugs. BTW, in the systemctl documentation there is no mention of "Yellow" dots - are they real in the systemctl output or have I screwed my terminal colour scheme? It seems they are services that "ain't really there". Is this too philosophical?