[systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Florian Weimer]

* Lennart Poettering:

> On Wed, 12.07.17 09:53, Florian Weimer (fw at deneb.enyo.de) wrote:
>
>> * Lennart Poettering:
>> 
>> > On Tue, 11.07.17 21:24, Florian Weimer (fw at deneb.enyo.de) wrote:
>> >
>> >> * Lennart Poettering:
>> >> 
>> >> > This all stems from my experiences with PulseAudio back in the day:
>> >> > People do not grok the effect of fork(): it only duplicates the
>> >> > invoking thread, not any other threads of the process, moreover all
>> >> > data structures are copied as they are, and that's a time bomb really:
>> >> 
>> >> These days, the PID can change even without a fork, so the story is a
>> >> bit different.
>> >
>> > Can you elaborate?
>> 
>> I'm no longer sure that the PID can change with the current kernel,
>> but I cannot rule it out, either.  But other weirdness is possible:
>> for example, after a fork, getpid and getppid could be equal.
>
> Please be less vague. So I understand correctly that the PID cannot
> change without fork after all?

I don't know.  I don't see such a guarantee provided by the kernel.

I think the important aspect is that as far as glibc is concerned, the
PID *can* change even if its fork and vfork functions are never
called, so we cannot reliably invalidate a cache.

We could decide that it is undefined to call the fork/vfork/clone
system calls directly, but that would break systemd functionality, I
think.

>> > Are you talking about cases where you invoke clone() directly, instead
>> > of via glibc's wrappers? We do that too in systemd, but I am not sure
>> > this is really reason enough to introduce this regression in glibc:
>> > this is easily worked around (which we do in systemd), and given that
>> > the time between clone() and execve() should be short, and the
>> > code between the two minimal this isn't really much of a problem.
>> 
>> There are other uses of clone which do not immediately lead to an
>> execve.
>
> Can you elaborate? Have a real-life user of this?

src/nspawn/nspawn.c?  A lot of things happen in the inner_child
function.

>> > Where was this discussed in detail? Do you have any links about the
>> > discussions about this?
>> 
>> It was on libc-alpha and the glibc bug tracker.
>
> Link?

https://sourceware.org/ml/libc-alpha/2016-10/msg00136.html
https://sourceware.org/ml/libc-alpha/2016-10/msg00233.html
https://sourceware.org/ml/libc-alpha/2016-11/msg00247.html
https://sourceware.org/ml/libc-alpha/2016-11/msg00303.html
https://www.postgresql.org/message-id/E1UKzBn-0006c6-Ep@gemulon.postgresql.org

The last reason explains why using getpid for fork detection does not
work in the way one would expect.