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

[Lennart Poettering]

On Fri, 05.09.14 13:25, Florian Weimer (fweimer at redhat.com) wrote:

> 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.

We are pretty conservative when it comes to calling stuff after
fork()ing. We do need malloc() working though. But there's nothing on
my list that we are currently missing there.

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

Well, the clone() syscall didn't use to be wrapped by glibc. If it is
now, and has been since a while we can certainly remove our manual
version and replace it with an invocation of the glibc wrapper.

Lennart

-- 
Lennart Poettering, Red Hat