nagios and freebsd threads issue : help please ...

[Daniel Eischen]

On Wed, 24 Aug 2005, Christophe Yayon wrote:

> Hi all,
>
> Here is my copy/paste from freebsd-hackers to nagios-devel list, and the
> answer from a Nagios developper.

Enough, please.  The POSIX standard says what it says for a reason.
Other OS's may appear to work, but there may in fact be race conditions
where thread library or libc data is left inconsistent after a fork().

>  >> likewise in base/commands.c fork is also called for similar things.
>  >> There's other places that also call popen...
>  >>
>  >>
>  >> 3. You can only execute async-signal-safe functions after a fork()
>  >> from a threaded application.  free(), malloc(), popen(), fgets(),
>  >> are not async-signal-safe.
>
>
> In a proper implementation they are. Read malloc/malloc.c from
> glibc-2.3.5 and you'll see. The first line of it reads

glibc is not a standard.

> Both of those links point to the same document, which is just the
> frameset for the navigation-frames.
>
> For async-safe functions, this is the proper url;
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_01
>
> For the fork() specification, the doc is here;
> http://www.opengroup.org/onlinepubs/009695399/functions/fork.html
>
> The 20'th bullet is this;
> -----------
> "A process shall be created with a single thread. If a multi-threaded
> process calls fork(), the new process shall contain a replica of the
> calling thread and its entire address space, possibly including the
> states of mutexes and other resources. Consequently, to avoid errors,
> the child process may only execute async-signal-safe operations until
> such time as one of the exec functions is called. [THR] [Option Start]
> Fork handlers may be established by means of the pthread_atfork()
> function in order to maintain application invariants across fork()
> calls. [Option End]
>
> When the application calls fork() from a signal handler and any of the
> fork handlers registered by pthread_atfork() calls a function that is
> not asynch-signal-safe, the behavior is undefined."
> -----------
>
> Also note that "From the application's perspective, a fork() call should
> appear atomic." which implicitly states fork() as an async-safe function
> although the following execution may not be. It also warns that improper
> implementations makes it less so.

This is crap.  fork() may be atomic() for the calling thread, but
that says nothing about the other threads and the remaining state
of the thread, libc, or other libraries the application is using.

>  >>
>  >> 4. Some FreeBSD developpers think that handling fork() in libpthread
> (and
>  >> probably libthr) than was done in libc_r.  We thought it better not
> to try
>  >> and reinitialize libpthread (and to some extent libc) because
>  >> it is messy and to expose non-portable applications.
>
>
> This is funny, because nagios apparently runs properly on Linux, HPUX,
> Solaris, Irix, AIX and Tru64. To me that seems to indicate that Nagios
> is very portable indeed and that the BSD fellows somehow botched it. I
> might be wrong, but...

Please, no more nagios problems.  If they do not want to go by
the standard, fine.

-- 
DE