From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 15:00:04 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 482E816A41F for ; Mon, 22 Aug 2005 15:00:04 +0000 (GMT) (envelope-from lists@nbux.com) Received: from smtp6.wanadoo.fr (smtp6.wanadoo.fr [193.252.22.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2690E43D5C for ; Mon, 22 Aug 2005 14:59:58 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0612.wanadoo.fr (SMTP Server) with ESMTP id 70BBE1C00151 for ; Mon, 22 Aug 2005 16:59:57 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152-22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf0612.wanadoo.fr (SMTP Server) with ESMTP id 28A3F1C00137; Mon, 22 Aug 2005 16:59:56 +0200 (CEST) X-ME-UUID: 20050822145957166.28A3F1C00137@mwinf0612.wanadoo.fr Received: from webmail.nbux.com (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id 10D4A1C4C89; Mon, 22 Aug 2005 16:59:56 +0200 (CEST) Received: from 194.51.215.62 (SquirrelMail authenticated user lists) by webmail.nbux.com with HTTP; Mon, 22 Aug 2005 16:59:56 +0200 (CEST) Message-ID: <40176.194.51.215.62.1124722796.squirrel@webmail.nbux.com> In-Reply-To: <20050822.080938.95905450.imp@bsdimp.com> References: <20050822.012017.22502074.imp@bsdimp.com> <20050822.080938.95905450.imp@bsdimp.com> Date: Mon, 22 Aug 2005 16:59:56 +0200 (CEST) From: "Christophe Yayon" To: "M. Warner Losh" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: deischen@freebsd.org, freebsd-hackers@freebsd.org, lists@nbux.com Subject: Re: nagios and freebsd threads issue : help please ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 15:00:04 -0000 Very good analysis ! In conclusion, it's clear that there bad functions calls in Nagios, i think i will copy/paste some lines from these mails and resume them to nagios-devel mailling list, i hope it will help nagios developper... Are you all ok for this ? > So there's something in the list, I've gone through and done a call > tree analysis to show the extensive and pervastive nature of the > functions that nagios calls after fork. I don't know if these are all > problems or not, since I don't know if some of these functions might > be called before the first thread is created with pthread_create. > However, any that are called after that clearly have undefined > behavior. > > In message: > Daniel Eischen writes: > : > So, if any of these things is an issue, and you can point to a posix > : > things that says it is an issue, then I think that the problem can be > : > resolved. > : > : You can only execute async-signal-safe functions after a fork() > : from a threaded application. free(), malloc(), popen(), fgets(), > : are not async-signal-safe. The list of async-signal-safe functions > : are here: > : > : http://www.opengroup.org/onlinepubs/009695399/nframe.html > > This can really be found at: > http://www.opengroup.org/onlinepubs/009695399/functions/chap02_04.html > > > The following table defines a set of functions that shall be either > reentrant or non-interruptible by signals and shall be > async-signal-safe. Therefore applications may invoke them, without > restriction, from signal-catching functions: > > _Exit, _exit, abort, accept, access, aio_error, aio_return, > aio_suspend, alarm, bind, cfgetispeed, cfgetospeed, cfsetispeed, > cfsetospeed, chdir, chmod, chown, clock_gettime, close, connect, > creat, dup, dup2, execle, execve, fchmod, fchown, fcntl, fdatasync, > fork, fpathconf, fstat, fsync, ftruncate, getegid, geteuid, getgid, > getgroups, getpeername, getpgrp, getpid, getppid, getsockname, > getsockopt, getuid, kill, link, listen, lseek, lstat, mkdir, mkfifo, > open, pathconf, pause, pipe, poll, posix_trace_event, pselect, raise, > read, readlink, recv, recvfrom, recvmsg, rename, rmdir, select, > sem_post, send, sendmsg, sendto, setgid, setpgid, setsid, setsockopt, > setuid, shutdown, sigaction, sigaddset, sigdelset, sigemptyset, > sigfillset, sigismember, sleep, signal, sigpause, sigpending, > sigprocmask, sigqueue, sigset, sigsuspend, sockatmark, socket, > socketpair, stat, symlink, sysconf, tcdrain, tcflow, tcflush, > tcgetattr, tcgetpgrp, tcsendbreak, tcsetattr, tcsetpgrp, time, > timer_getoverrun, timer_gettime, timer_settime, times, umask, uname, > unlink, utime, wait, waitpid, write > > [[Note, I reformatted the above ]]. > > : The restriction on fork() is here (20th bullet down): > : > : http://www.opengroup.org/onlinepubs/009695399/nframe.html > > http://www.opengroup.org/onlinepubs/009695399/functions/fork.html > > # 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. > > Later, in the informative section, we have: > > When a programmer is writing a multi-threaded program, the first > described use of fork(), creating new threads in the same program, > is provided by the pthread_create() function. The fork() function is > thus used only to run new programs, and the effects of calling > functions that require certain resources between the call to fork() > and the call to an exec function are undefined. > > Note, the 'certain resources' here means non-async-signal-safe > functions. > > This means that the following functions that nagios calls are unsafe: > > In set_macro_environment_var: > malloc, strcpy, strcat, setenv, unsetenv, free > In set_argv_macro_environment: > snprintf > In free_memory (only used in the USE_MEMORY_PERFORMANCE_TWEAKS): > free > > In my_system: > alarm, > (in the EMBEDDEDPERL case: > anything that perl can call, > strncpy, > printf) > popen, > strcpy, > fgets, > functions called by set_macro_environment_var, > set_argv_macro_environment, free_memory > > In daemon_init: > snprintf, getrlimit, setrlimit, sprintf and anything else > that's done as part of the daemon after daemon_init (I didn't > do a call graph analysis on this). > write_to_logs_and_console > cleanup > broker_program_state > > write_to_logs_and_console: > strlen, write_to_all_logs, write_to_console > > write_to_log > fopen, fprintf, fclose > > write_to_console > write_to_syslog > > write_to_all_logs > write_to_syslog, write_to_log > > write_to_syslog > syslog > > (in the DEBUG0 defined case: printf for nearly all functions) > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >