On 09/03/2014 08:45 PM, Lennart Poettering wrote:
On Sun, 31.08.14 03:31, Steven Stewart-Gallus
(sstewartgallu...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
