-
Bug
-
Resolution: Duplicate
-
Undefined
-
None
-
rhel-9.5
-
Yes
-
None
-
Regression
-
sst_security_selinux
-
ssg_security
-
None
-
False
-
-
None
-
None
-
None
-
Automated
-
None
What were you trying to do that didn't work?
Cockpit CI's weekly RHEL 9.5 image refresh detected a regression with systemd-coredump.
This seems to be a bit tricky – the image build log has a list of changed packages (grep for Changed:), but I fully dnf update'd our previous image and that still works fine. This only happens with a fresh install with the current cloud image.
Please provide the package NVR for which bug is seen:
systemd-252-35.el9.x86_64 works
kernel-core-5.14.0-457.el9 works
How reproducible: Always
Steps to reproduce
Get current RHEL 9.5 cloud image, boot it in QEMU, and get a root shell:
curl -o rhel.qcow -L http://download.devel.redhat.com/rhel-9/nightly/RHEL-9/latest-RHEL-9.5/compose/BaseOS/x86_64/images/rhel-guest-image-9.5-20240605.95.x86_64.qcow2 # nothing fancy, just admin:foobar and root:foobar curl -L -O https://github.com/cockpit-project/bots/raw/main/machine/cloud-init.iso qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=rhel.qcow,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::2201-:22 # password foobar ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 2201 admin@localhost # in ssh: sudo -i
Now trigger a crash:
hostnamectl # make sure the service is running pkill -ef -SEGV systemd-hostnamed
Expected results
In previous images, and Fedora, etc.
# coredumpctl TIME PID UID GID SIG COREFILE EXE SIZE Thu 2024-06-06 10:54:43 EDT 1517 0 0 SIGSEGV present /usr/lib/systemd/systemd-hostnamed 305.1K
and journal shows:
systemd-coredump[1520]: [🡕] Process 1517 (systemd-hostnam) of user 0 dumped core.
Stack trace of thread 1517:
#0 0x00007f92f910e23a epoll_wait (libc.so.6 + 0x10e23a)
#1 0x00007f92f9680958 sd_event_wait (libsystemd-shared-252.so + 0x280958)
#2 0x00007f92f9682c4b sd_event_run (libsystemd-shared-252.so + 0x282c4b)
#3 0x00007f92f94ac47c bus_event_loop_with_idle (libsystemd-shared-252.so + 0xac47c)
#4 0x0000560415d472e3 run (systemd-hostnamed + 0x72e3)
#5 0x0000560415d43efa main (systemd-hostnamed + 0x3efa)
#6 0x00007f92f9029590 __libc_start_call_main (libc.so.6 + 0x29590)
#7 0x00007f92f9029640 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x29640)
#8 0x0000560415d44075 _start (systemd-hostnamed + 0x4075)
ELF object binary architecture: AMD x86-64
systemd[1]: systemd-hostnamed.service: Main process exited, code=dumped, status=11/SEGV
systemd[1]: systemd-hostnamed.service: Failed with result 'core-dump'.
Actual results
On current image, there is nothing in "coredumpctl". Journal shows:
systemd-coredump[1633]: Failed to open our mntns: Permission denied systemd[1]: systemd-hostnamed.service: Main process exited, code=dumped, status=11/SEGV setroubleshoot[1636]: SELinux is preventing /usr/lib/systemd/systemd-coredump from read access on the file labeled nsfs_t. For complete SELinux messages run: sealert -l b9a70714-34e0-4041-9b98-1ba3de2d28eb
The suggested command doesn't actually work, though:
# sealert -l b9a70714-34e0-4041-9b98-1ba3de2d28eb Error query_alerts error (1003): id (b9a70714-34e0-4041-9b98-1ba3de2d28eb) not found
(That is a separate issue, though).
- duplicates
-
-
- Release Pending
-