+++ This bug was initially created as a clone of Bug #1443973 +++ The glibc PID cache negatively interacts with setting up containers and namespaces. Upstream commit: commit c579f48edba88380635ab98cb612030e3ed8691e Author: Adhemerval Zanella <adhemerval.zanella> Date: Mon Oct 10 15:08:39 2016 -0300 Remove cached PID/TID in clone
Already fixed in Fedora 26.
glibc-2.24-6.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-32940dd50d
glibc-2.24-6.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-32940dd50d
glibc-2.24-6.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
Umm, this change causes major slowdowns in various bits of systemd code, which assumes that getpid() is fast. libsystemd uses getpid() to detect when processes fork, to then politely return an error from all calls that operate on objects that cannot be reused after fork(). This used to be dead cheap on all glibc versions, but suddenly becomes excessively expensive, see this thread: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039195.html I find the explanation "The glibc PID cache negatively interacts with setting up containers and namespaces." quite weak... What is "negatively interacts" supposed to mean? Is this regression going to stay? I am kinda surprised by this change I must say, as it causes real problems, and there's no clear benefit of the change...
I opened a new bug 1469670 for tracking the regression introduced here.