[Bug libc/19429] syslog unusable after fork from a multi-threaded program

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19429

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Derek Snider from comment #1)
> Is there a work-around for this issue?

Ensure all other threads are not using syslog.

You can write a syslog interposer that takes a mutex around syslog and
serializes the calls to syslog. Your special forking code must take the syslog
lock first, fork, and then unlock the special lock if required and call syslog,
knowing that the internal syslog state is consistent.

Regarding signals, yes, fork can be interrupted to allow a signal handler to
run, in which case you _might_ see ERESTARTNOINTR when tracing the syscalls
(ptrace). The kernel transparently restarts the fork. An astute observer will
note that if your process size gets large enough you will have a 'restart loop'
where arriving signals, say profiling signals, have a period smaller the time
it takes to copy the process, which will force a restart, and the whole process
will repeat forever. This is a required implementation detail since POSIX says
the fork is atomic, and signals are either delivered to the parent, or the
parent and child, but at no point after the fork should the signal be lost and
not delivered to the child. To make fork "appear" to be atomic we must restart
it if the parent handles a signal.

Blocking all signals before fork is not a bad idea.

-- 
You are receiving this mail because:
You are on the CC list for the bug.