This happens whenever i try to populate my FEAUTRES="binpkg-multi-instance" binrepos with multiple configurations of the same package in parallel via application-containers that only share the binrepo. > !!! Binary package does not exist: '/var/cache/binpkgs/app-admin/sudo-1.9.10-r1.tbz2.9' > Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7f6691dd3900>>) > handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7f6691dd3900>>)> > Traceback (most recent call last): > File "/usr/lib/python3.9/asyncio/events.py", line 80, in _run > self._context.run(self._callback, *self._args) > File "/usr/lib/python3.9/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb > listener(self) > File "/usr/lib/python3.9/site-packages/_emerge/TaskSequence.py", line 49, in _task_exit_handler > self._start_next_task() > File "/usr/lib/python3.9/site-packages/_emerge/TaskSequence.py", line 43, in _start_next_task > self._start_task(task, self._task_exit_handler) > File "/usr/lib/python3.9/site-packages/_emerge/CompositeTask.py", line 112, in _start_task > task.start() > File "/usr/lib/python3.9/site-packages/_emerge/AsynchronousTask.py", line 34, in start > self._start() > File "/usr/lib/python3.9/site-packages/_emerge/EbuildBuild.py", line 519, in _start > self.ebuild_build._record_binpkg_info(self.ebuild_binpkg) > File "/usr/lib/python3.9/site-packages/_emerge/EbuildBuild.py", line 561, in _record_binpkg_info > "BINPKGMD5": "%s\n" % pkg._metadata["MD5"], > AttributeError: 'NoneType' object has no attribute '_metadata' > Terminated The cause is using portage.getpid() to compose a unique temporary filename within the PKGDIR: https://gitweb.gentoo.org/proj/portage.git/tree/lib/_emerge/EbuildBinpkg.py?id=b094ba47368bb9b16fb17ee47a54644a09860823#n29 > !!! Binary package does not exist: '/var/cache/binpkgs/app-admin/sudo-1.9.10-r1.tbz2.9' In this case, 2+ emerge processes running with the same PID (because they were run with an unshared PID namespace) tried to create binpkgs for app-admin/sudo-1.9.10-r1. Is there a specific reason why portage.getpid() is used to generate a (seemingly) unique temporary file name for the ebuild package phase? Reproducible: Always
I suspect nobody thought of it, i.e. no good reason.
portage.getpid() was a good way to avoid collision in a single system, but if you try build on multiple systems, this could occur. I don't think we want to use a lock system on remote filesystem. So maybe create a long random hex instead of pid?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=de19f3a7215d64d22dcc0f779314de1f1199963f commit de19f3a7215d64d22dcc0f779314de1f1199963f Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2024-05-27 18:47:30 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2024-05-27 20:01:49 +0000 atomic_ofstream: Use mkstemp rather than getpid (pid namespace safety) Bug: https://bugs.gentoo.org/851015 Signed-off-by: Zac Medico <zmedico@gentoo.org> lib/portage/util/__init__.py | 47 ++++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 19 deletions(-)
