Bug 2097865
Summary: | Removing podman-2:4.0.2-6.module+el8.6.0+14877+f643d2d6.x86_64 does not remove podman socket if sudo systemctl enable podman.socket has been run prior to yum remove podman | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Matt Mezynski <mmezynsk> |
Component: | podman | Assignee: | Jindrich Novy <jnovy> |
Status: | CLOSED ERRATA | QA Contact: | Joy Pu <ypu> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.6 | CC: | bbaude, dwalsh, jligon, jnovy, lsm5, lsm5, mheon, peter.vreman, pthomas, tsweeney, umohnani, vrothber, ypu |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | podman-4.1.1-4.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-11-08 09:16:27 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: |
Description
Matt Mezynski
2022-06-16 18:46:37 UTC
I added this to the podman spec file: %postun systemctl stop podman.socket > /dev/null 2>&1 systemctl disable podman.socket > /dev/null 2>&1 : Should that only be done, if this is a full removal? IE On upgrade will this leave us in a bad state. Makes sense. I changed it to: %postun if [ $1 == 0 ]; then systemctl stop podman.socket > /dev/null 2>&1 systemctl disable podman.socket > /dev/null 2>&1 fi : to assure it's executed on removal only. Now, the last question - does it make sense to run this before or after podman package removal? Assuming in %postun, not %preun to not to step on podman's (still installed) feet? I would think it has to be PREUN, since those commands are likely (POtentially) to execute podman commands. Do we need to do systemctl stop podman.service systemctl disable podman.service as well. Ok, the final variant looks like this: %preun if [ $1 == 0 ]; then systemctl stop podman.service > /dev/null 2>&1 systemctl stop podman.socket > /dev/null 2>&1 systemctl disable podman.service > /dev/null 2>&1 systemctl disable podman.socket > /dev/null 2>&1 fi : Dan, PTAL LGTM Checked with podman-2:4.1.1-6.module+el8.7.0+15895+a6753917.x86_64 and after remove the podman rpm, the podman.socket files are clean up as expected. More details: Output from step 4: [root@sweetpig-21 ~]# ls -l /etc/systemd/system/sockets.target.wants total 0 lrwxrwxrwx. 1 root root 39 Jul 15 05:55 dm-event.socket -> /usr/lib/systemd/system/dm-event.socket lrwxrwxrwx. 1 root root 39 Jul 15 05:55 sssd-kcm.socket -> /usr/lib/systemd/system/sssd-kcm.socket [root@sweetpig-21 ~]# ls /usr/lib/systemd/system/podman.socket ls: cannot access '/usr/lib/systemd/system/podman.socket': No such file or directory So set Tested flag. Tested with podman-2:4.2.0-1.module+el8.7.0+16493+89f82ab8.x86_64 and the output from step 4: # ls -l /etc/systemd/system/sockets.target.wants total 0 lrwxrwxrwx. 1 root root 39 Aug 29 09:39 dm-event.socket -> /usr/lib/systemd/system/dm-event.socket lrwxrwxrwx. 1 root root 39 Aug 29 09:39 sssd-kcm.socket -> /usr/lib/systemd/system/sssd-kcm.socket So move it to verified. 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 (Moderate: container-tools:rhel8 security, 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/RHSA-2022:7457 |