[systemd-devel] You are invited to give your thoughts on some async-signal-safety issues.

[Florian Weimer]

On 09/03/2014 08:45 PM, Lennart Poettering wrote:
> On Sun, 31.08.14 03:31, Steven Stewart-Gallus (sstewartgallus00 at mylangara.bc.ca) wrote:
>> I understand that systemd uses sandboxing and multithreading.  After a
>> fork, many things are messed up so it's only practical to use
>> async-signal-safe functions after a fork from a threaded program.  If
>> you have ideas on what sort of functionality GLibc needs to change to
>> make systemd more async-signal-safe after a fork you are invited to
>> give your thoughts on the GLibc mailing list in the thread at
>> https://sourceware.org/ml/libc-help/2014-08/msg00039.html.
>
> All our APIs contain checks that you cannot continue reuse contexts
> you create with them after a fork(). If you try the functions will
> return ESRCH.

Steven is asking about what you need for glibc beyond what the standards 
provide.  Things like malloc support, access to NSS databases, and so 
on.  For example, bus_kernel_make_starter is called after forking and 
does a lot of things.

But the real question is what you would need to get rid of the 
syscall(__NR_clone) in src/nspawn/nspawn.c.

-- 
Florian Weimer / Red Hat Product Security