At different times I'm seeing a number of the following warnings: warning: runaway fork() in Lua script which seem to be coming from rpm, even if it may not be the fault of rpm but rather some other macro. Reproducible: Always Steps to Reproduce: 1. fedpkg clone conda 2. cd conda 3. fedpkg build --scratch Actual Results: $ fedpkg build warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script warning: runaway fork() in Lua script Building conda-23.9.0-6.fc38 for f38-candidate Created task: 110311175 ... Expected Results: No messages rpm-4.19.1-1.fc40.x86_64 Other macros: ansible-srpm-macros-1-11.fc39.noarch blender-rpm-macros-4.0.2-1.fc40.noarch cargo-rpm-macros-25.2-2.fc40.noarch cmake-rpm-macros-3.27.7-1.fc40.noarch efi-srpm-macros-5-9.fc39.noarch fonts-rpm-macros-2.0.5-12.fc39.noarch fonts-srpm-macros-2.0.5-12.fc39.noarch forge-srpm-macros-0.2.0-1.fc40.noarch fpc-srpm-macros-1.3-8.fc39.noarch ghc-srpm-macros-1.6.1-3.fc40.noarch gnat-srpm-macros-6-3.fc39.noarch go-rpm-macros-3.3.1-1.fc40.x86_64 go-srpm-macros-3.3.1-1.fc40.noarch kernel-srpm-macros-1.0-20.fc39.noarch kf5-rpm-macros-5.113.0-1.fc40.noarch lua-rpm-macros-1-9.fc39.noarch lua-srpm-macros-1-9.fc39.noarch MUMPS-srpm-macros-5.5.1-6.fc40.noarch ocaml-srpm-macros-9-1.fc40.noarch openblas-srpm-macros-2-14.fc39.noarch package-notes-srpm-macros-0.5-9.fc39.noarch perl-srpm-macros-1-51.fc39.noarch pyproject-rpm-macros-1.10.0-1.fc40.noarch pyproject-srpm-macros-1.10.0-1.fc40.noarch python3-rpm-macros-3.12-5.fc40.noarch python-pyqt6-rpm-macros-6.6.1-1.fc40.noarch python-qt5-rpm-macros-5.15.10-1.fc40.noarch python-rpm-macros-3.12-5.fc40.noarch python-srpm-macros-3.12-5.fc40.noarch qt5-rpm-macros-5.15.11-1.fc40.noarch qt5-srpm-macros-5.15.11-1.fc40.noarch qt6-rpm-macros-6.6.1-1.fc40.noarch qt6-srpm-macros-6.6.1-1.fc40.noarch R-rpm-macros-1.2.1-7.fc39.noarch rust-srpm-macros-25.2-2.fc40.noarch systemd-rpm-macros-255-1.fc40.noarch
This is a bug in a somebodys Lua script/macro: it called posix.fork() but didn't wait for the child. It's also not reproducable for me (on F39), which suggests something in rawhide or your local system: [pmatilai🎩︎localhost conda]$ fedpkg build --scratch Building conda-23.11.0-1.fc40 for rawhide Created task: 110318892 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=110318892 Watching tasks (this may be safely interrupted)... ...but then I don't have half of those macro packages installed. conda uses pyproject, python and rpmautospec macros but I didn't see anything fishy in those. Which makes it all the more suspicious. 'rpm --showrc|grep posix.fork' ought to show something. Locating the actual origin may well be easier by grepping for posix.fork in /usr/lib/rpm/macros.d (and if that doesn't turn anything up, ~/.rpmmacros and /etc/rpm/*), there aren't many hits expected.
I'm also not seeing that on a F40 container with all of the above macro packages installed (with 'fedpkg local', can't easily test 'build' there).
Thank you for the suggestsions. I've removed about as much rpm macros as a I can, but am still getting the message. `rpm --showrc | grep posix.fork' doesn't show anything. Looking at strace it seems to be coming when parsing the various /tmp/rpmautospec-abridged-conda-ahzr_ypd.spec files. These files seem to be corrupted, e.g. this section: URL: http://conda.pydata.org/docs/ Source0: https://github.com/conda/conda/archive/%{version}/%{name}-%{version}.tar.gz # bash completion script moved to a separate project Source1: https://raw.githubusercontent.com/tartansandal/conda-bash-completion/1.7/conda Patch0: conda_sys_prefix.patch # Use main entry point for conda and re-add conda-env entry point, no n eed to run conda init Patch1: 0001-Use-main-entry-point-for-conda-and-re-add-conda-env-.patch # Use system cpuinfo Patch3: conda-cpuinfo.patch # Fix tests on 32bit # https://github.com/conda/conda/pull/9759 #Patch4 : conda-32bit.patch newlines have been inserted. Interestingly, if I remove this section: --- a/conda.spec +++ b/conda.spec @@ -18,10 +18,6 @@ Patch0: conda_sys_prefix.patch Patch1: 0001-Use-main-entry-point-for-conda-and-re-add-conda-env-.patch # Use system cpuinfo Patch3: conda-cpuinfo.patch -# Fix tests on 32bit -# https://github.com/conda/conda/pull/9759 -#Patch4: conda-32bit.patch - Patch10004: 0004-Do-not-try-to-run-usr-bin-python.patch Patch10005: 0005-Fix-failing-tests-in-test_api.py.patch Patch10006: 0006-shell-assume-shell-plugins-are-in-etc.patch then the messages go away.
The abridged file is generated in https://github.com/fedora-infra/rpmautospec/commit/af654c41ff681aa1b0b6cc7bed405cf95d019ebf I wonder why the additional newlines.
Right, I figured it may well be autospec related, and indeed I can reproduce with 'fedpkg build' if I update to rpmautospec from rawhide. It probably an rpmautospec issue then, but this does seem quite peculiar. Do you have a way to reproduce this without 'fedpkg build'? It's not the nicest thing to debug and experiment with.
I'm not following what happens in this all, really, but nosing around I get a feeling an actual fork from Lua has nothing to do with it. This probably also doesn't happen in F38 with the latest rpmautospec (if somebody can check, that'd be nice) as the "runaway" detection changed in 4.19: https://github.com/rpm-software-management/rpm/commit/a8107659ef3dd4855729bf65aa4d70f784cb5a5f in a way that probably catches more than it should: it's waiting for anything in the same process group, and the inside out and upside down way how this all gets called inside rpmautospec is probably what ends up triggering this message.
The more I think about it, I don't think rpmautospec is to blame. The "runaway lua" check in rpm seems plain wrong now that I look at it, so I'd keep this on rpm-side for now.
Should be fixed in rpm-4.19.1-2.fc40 in rawhide now. The height of embarrasment was that the "improved" detection was actually failing to warn on a real runaway child in our test suite :facepalm:
Hmm, I wonder if the original report could be related to this change in glibc: https://src.fedoraproject.org/rpms/glibc/c/259d575cdf1efb48b486811f4faadbcd836f0cbc?branch=rawhide
Looks good to me. Thank you for the quick fix.
(In reply to Stephen Gallagher from comment #9) > Hmm, I wonder if the original report could be related to this change in > glibc: > https://src.fedoraproject.org/rpms/glibc/c/ > 259d575cdf1efb48b486811f4faadbcd836f0cbc?branch=rawhide Those would occur during package installation, the report here happens when parsing the spec, and even then the glibc scriptlets do an exec() after the fork so this would only happen if that exec failed, and in that case you'd see other errors too. Anyway, closing as per Orion's comment.
This is now happening in Fedora 39 with rpm-4.19.1-1.fc39. The fix https://src.fedoraproject.org/rpms/rpm/c/0ae9b336476cfc4291411bc004c79d554e32b83d?branch=rawhide has not made it to Fedora 39.
I've opened https://src.fedoraproject.org/rpms/rpm/pull-request/53
FEDORA-2024-9fb108bd3b has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-9fb108bd3b
FEDORA-2024-9fb108bd3b has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-9fb108bd3b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-9fb108bd3b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-9fb108bd3b has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.