#9465 Need to obtain a coredump from systemctl from a koji build
Closed: It's all good by tmraz. Opened by tmraz.

  • Describe the issue
    So after a minor change in openssl in Rawhide related to FIPS the systemctl started to segfault during the buildroot installs in koji when it is called from the rpm post install scripts. Unfortunately the problem is not reproducible with local mock builds. Would it be possible to obtain a coredump from the segfaulting systemctl?

  • When do you need this? (YYYY/MM/DD)
    ASAP

  • When is this no longer needed or useful? (YYYY/MM/DD)

  • If we cannot complete your request, what is the impact?
    No idea how to further investigate the problem without a reproducer or core dump.


Example of the build where the segfaults happen:
https://koji.fedoraproject.org/koji/taskinfo?taskID=44698142

Note the bug isn't currently happening as I did an openssl build with the change that causes the bug reverted. The most recent build where the bug happened was probably this one, if the artifacts from that have gone by now, we may need to set up a side tag with the bad openssl or something...

@adamw gave me a latest koji task and I grabbed the coredumps for the x86_64 task.

I am attaching the coredumps for that x86_64 task here.

core.udevadm.0.b812e7d02b664804b7972f0fed359266.4125717.1589934800000000000000.lz4core.systemd-tmpfile.0.b812e7d02b664804b7972f0fed359266.4125617.1589934797000000000000.lz4core.systemd-random-.0.b812e7d02b664804b7972f0fed359266.4125727.1589934801000000000000.lz4core.systemd-machine.0.b812e7d02b664804b7972f0fed359266.4125599.1589934796000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125773.1589934804000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125765.1589934803000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125740.1589934803000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125720.1589934800000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125687.1589934799000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125684.1589934799000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125654.1589934799000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125650.1589934798000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125639.1589934798000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125632.1589934797000000000000.lz4core.systemctl.0.b812e7d02b664804b7972f0fed359266.4125602.1589934796000000000000.lz4core.sort.0.b812e7d02b664804b7972f0fed359266.4125798.1589934807000000000000.lz4core.sort.0.b812e7d02b664804b7972f0fed359266.4125793.1589934806000000000000.lz4core.sort.0.b812e7d02b664804b7972f0fed359266.4125358.1589934765000000000000.lz4core.sort.0.b812e7d02b664804b7972f0fed359266.4125352.1589934764000000000000.lz4core.journalctl.0.b812e7d02b664804b7972f0fed359266.4125610.1589934796000000000000.lz4

Thank you very much.

Metadata Update from @tmraz:
- Issue close_status updated to: It's all good
- Issue status updated to: Closed (was: Open)

Closing the ticket.

Metadata