Date: Wed, 21 Feb 2007 00:03:10 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Martin Blapp <mb@imp.ch> Cc: rob@debank.tv, freebsd-threads@freebsd.org Subject: Re: 6.2-Release and Clamd 0.90 with libpthread.so Message-ID: <Pine.GSO.4.64.0702202357500.15602@sea.ntplx.net> In-Reply-To: <20070221020335.Y4139@godot.imp.ch> References: <20070220153632.E4139@godot.imp.ch> <Pine.GSO.4.64.0702201138080.12034@sea.ntplx.net> <20070220174221.B4139@godot.imp.ch> <Pine.GSO.4.64.0702201145420.12034@sea.ntplx.net> <20070220190347.C4139@godot.imp.ch> <Pine.GSO.4.64.0702201319230.12034@sea.ntplx.net> <20070220225303.V4139@godot.imp.ch> <Pine.GSO.4.64.0702201724590.12034@sea.ntplx.net> <20070220234734.H4139@godot.imp.ch> <20070221000830.V4139@godot.imp.ch> <20070221020335.Y4139@godot.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 21 Feb 2007, Martin Blapp wrote: >> Sigh, >> >>> >>> Useing daemon(3) instead of fork seems to fix the problem. >> >> Of course deamon(3) calls fork, and after a short time I >> had again the same ktrace output and CPU usage. > > Using daemon(3) works some times, but from time to time > I see then again the old behaviour, looping kse calls > and some forks(). > > I wonder why those calls never happen in the libthr > and libc_r cases. libc_r and libthr don't have to kse initialization and have different locking. Regardless, I think the code (clamd) is wrong. There is no guarantee that fork() from threaded application will work for libthr and libc_r either. If clamd needs to daemonize, it can always exec() itself with an added argument that means "I've already fork()'d, don't fork() again". -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0702202357500.15602>