From mahatma at bspu.unibel.by Mon Dec 3 18:44:05 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Mon, 03 Dec 2012 20:44:05 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) Message-ID: <50BCE4E5.1010801@bspu.unibel.by> Better later then nothing;). Somebody asks about APC PHP cache & mpm-itk long time ago. No. Better to not use APC now. Long time I use this cache & have multiple "child died" message and even do apache health verify in cron (even with vanilla mpm-itk). This is only becouse similar project "eaccelerator" temporary stagnating and do not support PHP 5.4. Now all OK and better to use eaccelerator (from github) - no problems even with vfork() (I in doubts only about cache security). PS All about apache 2.2 -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From tino at didriksen.cc Mon Dec 3 19:52:12 2012 From: tino at didriksen.cc (Tino Didriksen) Date: Mon, 3 Dec 2012 19:52:12 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BCE4E5.1010801@bspu.unibel.by> References: <50BCE4E5.1010801@bspu.unibel.by> Message-ID: As a counterpoint, I've used APC with MPM-ITK on Apache 2.2.x for years without any problems. Most recently, via Ubuntu Server's apache2-mpm-itk and php-apc packages. Getting it all into a Just Works state is as simple as apt-get install apache2-mpm-itk php-apc Before that setup, I had to modify the ITK sources to allow more shared memory capabilities, but it worked. -- Tino Didriksen On Mon, Dec 3, 2012 at 6:44 PM, Dzianis Kahanovich wrote: > Better later then nothing;). > Somebody asks about APC PHP cache & mpm-itk long time ago. > > No. Better to not use APC now. Long time I use this cache & have multiple > "child > died" message and even do apache health verify in cron (even with vanilla > mpm-itk). This is only becouse similar project "eaccelerator" temporary > stagnating and do not support PHP 5.4. Now all OK and better to use > eaccelerator > (from github) - no problems even with vfork() (I in doubts only about cache > security). > > PS All about apache 2.2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca at thirdeye.it Mon Dec 3 19:55:26 2012 From: gianluca at thirdeye.it (Gianluca Zamagni) Date: Mon, 3 Dec 2012 19:55:26 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: References: <50BCE4E5.1010801@bspu.unibel.by> Message-ID: Il giorno 03/dic/2012, alle ore 19:52, Tino Didriksen ha scritto: > As a counterpoint, I've used APC with MPM-ITK on Apache 2.2.x for years without any problems. Most recently, via Ubuntu Server's apache2-mpm-itk and php-apc packages. Getting it all into a Just Works state is as simple as apt-get install apache2-mpm-itk php-apc > > Before that setup, I had to modify the ITK sources to allow more shared memory capabilities, but it worked. Me too. Using it on Debian 64 Bit since six months, on 20 servers with at least 200 account per server. Just compiled APC from pear, but it works like a charm. The only thing I've noted is that old CMS (like Joomla 1.5) have some issues in this configuration, but just disable APC from the .htaccess for these virtualhost and you're good to go. Gianluca -- UNIX Sysadmin - Apple ACTC ACDT ACHDES ACTC Certified ? Third Eye Consulting di Zamagni Gianluca ? em at il. info at thirdeye.it - tel. 3288242325 SAVE PAPER think before print this email -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahatma at bspu.unibel.by Tue Dec 4 12:27:52 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Tue, 04 Dec 2012 14:27:52 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: References: <50BCE4E5.1010801@bspu.unibel.by> Message-ID: <50BDDE38.9080307@bspu.unibel.by> I don't fix time of starting problems, but it can be related from versions (apache, etc). Last "working" state was random "child died on signal 11" (not precise), but all still working (under reverse proxy acceleration). Only sometimes apache died whole, checked in cron. Also I use vfork() in mpm-itk, IMHO first time with APC it works good, but after some of updates it died same. I use Gentoo with "~amd64/~x86" flags - "developer" or "unstable" (just latest versions of packages). Also APC used with flags "lock_spinlock mmap" (default locking threaded and don't work with mpm-itk). May be your shared memory ITK modifications crytical? But eaccelerator "just work" without pain. Tino Didriksen ?????: > As a counterpoint, I've used APC with MPM-ITK on Apache 2.2.x for years > without any problems. Most recently, via Ubuntu Server's apache2-mpm-itk > and php-apc packages. Getting it all into a Just Works state is as simple > as apt-get install apache2-mpm-itk php-apc > > Before that setup, I had to modify the ITK sources to allow more shared > memory capabilities, but it worked. > > -- Tino Didriksen > > On Mon, Dec 3, 2012 at 6:44 PM, Dzianis Kahanovich > wrote: > >> Better later then nothing;). >> Somebody asks about APC PHP cache & mpm-itk long time ago. >> >> No. Better to not use APC now. Long time I use this cache & have multiple >> "child >> died" message and even do apache health verify in cron (even with vanilla >> mpm-itk). This is only becouse similar project "eaccelerator" temporary >> stagnating and do not support PHP 5.4. Now all OK and better to use >> eaccelerator >> (from github) - no problems even with vfork() (I in doubts only about cache >> security). >> >> PS All about apache 2.2 >> > -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From mahatma at bspu.unibel.by Tue Dec 4 12:43:03 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Tue, 04 Dec 2012 14:43:03 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BDDE38.9080307@bspu.unibel.by> References: <50BCE4E5.1010801@bspu.unibel.by> <50BDDE38.9080307@bspu.unibel.by> Message-ID: <50BDE1C7.1000808@bspu.unibel.by> One more: possible difference with Ubuntu can be: Gentoo trying to force non-threaded versions of php/mod_php with non-threaded MPMs (so, Gentoo installs all from sources with compile-time flags). But APR - paradox - built with auto-detected threads (on). It easy to fix and sometimes I think about it, but do not trying to make it with/without threads. Ubuntu (IMHO) installing more unifyed binary versions (threaded PHP + non-threaded Apache-ITK)? Dzianis Kahanovich ?????: > I don't fix time of starting problems, but it can be related from versions > (apache, etc). Last "working" state was random "child died on signal 11" (not > precise), but all still working (under reverse proxy acceleration). Only > sometimes apache died whole, checked in cron. Also I use vfork() in mpm-itk, > IMHO first time with APC it works good, but after some of updates it died same. > > I use Gentoo with "~amd64/~x86" flags - "developer" or "unstable" (just latest > versions of packages). Also APC used with flags "lock_spinlock mmap" (default > locking threaded and don't work with mpm-itk). > > May be your shared memory ITK modifications crytical? But eaccelerator "just > work" without pain. > > Tino Didriksen ?????: >> As a counterpoint, I've used APC with MPM-ITK on Apache 2.2.x for years >> without any problems. Most recently, via Ubuntu Server's apache2-mpm-itk >> and php-apc packages. Getting it all into a Just Works state is as simple >> as apt-get install apache2-mpm-itk php-apc >> >> Before that setup, I had to modify the ITK sources to allow more shared >> memory capabilities, but it worked. >> >> -- Tino Didriksen >> >> On Mon, Dec 3, 2012 at 6:44 PM, Dzianis Kahanovich >> wrote: >> >>> Better later then nothing;). >>> Somebody asks about APC PHP cache & mpm-itk long time ago. >>> >>> No. Better to not use APC now. Long time I use this cache & have multiple >>> "child >>> died" message and even do apache health verify in cron (even with vanilla >>> mpm-itk). This is only becouse similar project "eaccelerator" temporary >>> stagnating and do not support PHP 5.4. Now all OK and better to use >>> eaccelerator >>> (from github) - no problems even with vfork() (I in doubts only about cache >>> security). >>> >>> PS All about apache 2.2 >>> >> > > -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From mahatma at bspu.unibel.by Tue Dec 4 15:07:18 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Tue, 04 Dec 2012 17:07:18 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: References: <50BCE4E5.1010801@bspu.unibel.by>

Message-ID: <50BE0396.80308@bspu.unibel.by> Gianluca Zamagni ?????: >> As a counterpoint, I've used APC with MPM-ITK on Apache 2.2.x for years without any problems. Most recently, via Ubuntu Server's apache2-mpm-itk and php-apc packages. Getting it all into a Just Works state is as simple as apt-get install apache2-mpm-itk php-apc >> >> Before that setup, I had to modify the ITK sources to allow more shared memory capabilities, but it worked. > > > Me too. Using it on Debian 64 Bit since six months, on 20 servers with at least 200 account per server. Just compiled APC from pear, but it works like a charm. > > The only thing I've noted is that old CMS (like Joomla 1.5) have some issues in this configuration, but just disable APC from the .htaccess for these virtualhost and you're good to go. HMM. I don't remember why I shut-off default pthreadmutex, but now I try to rebuild it with default options (+mmap) - it works... while... may be you right... -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From mahatma at bspu.unibel.by Tue Dec 4 17:00:14 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Tue, 04 Dec 2012 19:00:14 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: References: <50BCE4E5.1010801@bspu.unibel.by>

Message-ID: <50BE1E0E.2050104@bspu.unibel.by> Gianluca Zamagni ?????: >> As a counterpoint, I've used APC with MPM-ITK on Apache 2.2.x for years without any problems. Most recently, via Ubuntu Server's apache2-mpm-itk and php-apc packages. Getting it all into a Just Works state is as simple as apt-get install apache2-mpm-itk php-apc >> >> Before that setup, I had to modify the ITK sources to allow more shared memory capabilities, but it worked. > > > Me too. Using it on Debian 64 Bit since six months, on 20 servers with at least 200 account per server. Just compiled APC from pear, but it works like a charm. > > The only thing I've noted is that old CMS (like Joomla 1.5) have some issues in this configuration, but just disable APC from the .htaccess for these virtualhost and you're good to go. Yes, I remember why I always change lock method from default pthreadmutex. IMHO locking must work across all apache+PHP instances, but ITK is non-threaded and threaded locking just not work across processes. So, default APC installation for ITK must completely ignoring locking, required for single RAM pool usage. Fixme? -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From sgunderson at bigfoot.com Tue Dec 4 17:16:03 2012 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Tue, 4 Dec 2012 17:16:03 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BE1E0E.2050104@bspu.unibel.by> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> Message-ID: <20121204161603.GB9771@uio.no> On Tue, Dec 04, 2012 at 07:00:14PM +0300, Dzianis Kahanovich wrote: > Yes, I remember why I always change lock method from default pthreadmutex. > IMHO locking must work across all apache+PHP instances, but ITK is > non-threaded and threaded locking just not work across processes. I don't really know anything about apc, but this is as far as I know not correct; pthread mutexes can be shared and synchronize across processes just as well as between threads. See in particular the pthread_mutexattr_setpshared() call. /* Steinar */ -- Homepage: http://www.sesse.net/ From mahatma at bspu.unibel.by Wed Dec 5 11:30:49 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Wed, 05 Dec 2012 13:30:49 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <20121204161603.GB9771@uio.no> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> Message-ID: <50BF2259.2040009@bspu.unibel.by> Steinar H. Gunderson ?????: >> Yes, I remember why I always change lock method from default pthreadmutex. >> IMHO locking must work across all apache+PHP instances, but ITK is >> non-threaded and threaded locking just not work across processes. > > I don't really know anything about apc, but this is as far as I know not > correct; pthread mutexes can be shared and synchronize across processes just > as well as between threads. See in particular the > pthread_mutexattr_setpshared() call. Thanks, good. But after day of work with pthread mutexes I got multiple "child died with signal 11" and even cron's restart. But it may be result of "my vfork()" (CLONE_VFORK here). OK, I will silently test and select eaccelerator or no vfork() without later flood... It may be also result of various PHP features ("non-mainstream" related to binary distros), trying to work with background process, or even mmap. -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From sgunderson at bigfoot.com Wed Dec 5 16:39:11 2012 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Wed, 5 Dec 2012 16:39:11 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BF2259.2040009@bspu.unibel.by> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> Message-ID: <20121205153911.GA30045@uio.no> On Wed, Dec 05, 2012 at 01:30:49PM +0300, Dzianis Kahanovich wrote: > Thanks, good. But after day of work with pthread mutexes I got multiple "child > died with signal 11" and even cron's restart. If cron restarts, that's probably an issue with cron, not with pthreads. :-) If a child dies with signal 11, you should probably try to get a backtrace. The Apache wiki has more information: http://httpd.apache.org/dev/debugging.html > But it may be result of "my vfork()" (CLONE_VFORK here). Note that vfork() is really only ever intended to be followed by execve() (or _exit()). /* Steinar */ -- Homepage: http://www.sesse.net/ From gianluca at thirdeye.it Wed Dec 5 16:41:53 2012 From: gianluca at thirdeye.it (Gianluca Zamagni) Date: Wed, 5 Dec 2012 16:41:53 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <20121205153911.GA30045@uio.no> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> Message-ID: <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> Il giorno 05/dic/2012, alle ore 16:39, "Steinar H. Gunderson" ha scritto: > On Wed, Dec 05, 2012 at 01:30:49PM +0300, Dzianis Kahanovich wrote: >> Thanks, good. But after day of work with pthread mutexes I got multiple "child >> died with signal 11" and even cron's restart. > > If cron restarts, that's probably an issue with cron, not with pthreads. :-) I thinks that he mean that when Apache's child died from signal 11 he restart the webserver with a cron script (that I'd like to see), and not that the crond die. Actually I've checked some logs and I see the same child diying. I use APC too. Gianluca -- UNIX Sysadmin - Apple ACTC ACDT ACHDES ACTC Certified ? Third Eye Consulting di Zamagni Gianluca ? em at il. info at thirdeye.it - tel. 3288242325 SAVE PAPER think before print this email -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomassen at a4a.de Wed Dec 5 16:49:24 2012 From: thomassen at a4a.de (Peter Thomassen) Date: Wed, 05 Dec 2012 16:49:24 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> Message-ID: <50BF6D04.2040802@a4a.de> Hi, I also see this issue with APC + itk in a bit less than 0.1% of the requests to .php files. I recently switched to XCache due to another issue I was experiencing (APC cache was occasionally corrupted for Joomla installations). So far, with XCache everything is fine. Best, Peter On 12/05/2012 04:41 PM, Gianluca Zamagni wrote: > > Il giorno 05/dic/2012, alle ore 16:39, "Steinar H. Gunderson" > > ha scritto: > >> On Wed, Dec 05, 2012 at 01:30:49PM +0300, Dzianis Kahanovich wrote: >>> Thanks, good. But after day of work with pthread mutexes I got >>> multiple "child >>> died with signal 11" and even cron's restart. >> >> If cron restarts, that's probably an issue with cron, not with >> pthreads. :-) > > I thinks that he mean that when Apache's child died from signal 11 he > restart the webserver with a cron script (that I'd like to see), and not > that the crond die. > > Actually I've checked some logs and I see the same child diying. I use > APC too. > > Gianluca > -- > UNIX Sysadmin - Apple ACTC ACDT ACHDES ACTC Certified > ? Third Eye Consulting di Zamagni Gianluca ? > em at il. info at thirdeye.it - tel. 3288242325 > * > * > * > SAVE PAPER*think before print this email > > > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > -- Mit freundlichen Gr??en Peter Thomassen ------------------------------------------ a4a GmbH Scheffelstr. 14 D-97072 W?rzburg Telefon: +49-931-2705351 Telefax: +49-931-27049942 Web: http://www.a4a.de/ E-Mail: info at a4a.de Gesch?ftsf?hrer: Peter Thomassen Registergericht AG W?rzburg HRB 10041 USt-IdNr.: DE263344753 From gianluca at thirdeye.it Wed Dec 5 16:51:13 2012 From: gianluca at thirdeye.it (Gianluca Zamagni) Date: Wed, 5 Dec 2012 16:51:13 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BF6D04.2040802@a4a.de> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> <50BF6D04.2040802@a4a.de> Message-ID: Il giorno 05/dic/2012, alle ore 16:49, Peter Thomassen ha scritto: > Hi, > > I also see this issue with APC + itk in a bit less than 0.1% of the requests to .php files. > > I recently switched to XCache due to another issue I was experiencing (APC cache was occasionally corrupted for Joomla installations). The same here, with Joomla 1.5 > So far, with XCache everything is fine. Good peformance even with ITK? Gianluca -- UNIX Sysadmin - Apple ACTC ACDT ACHDES ACTC Certified ? Third Eye Consulting di Zamagni Gianluca ? em at il. info at thirdeye.it - tel. 3288242325 SAVE PAPER think before print this email -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomassen at a4a.de Wed Dec 5 16:51:55 2012 From: thomassen at a4a.de (Peter Thomassen) Date: Wed, 05 Dec 2012 16:51:55 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BF6D04.2040802@a4a.de> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> <50BF6D04.2040802@a4a.de> Message-ID: <50BF6D9B.1030707@a4a.de> Sorry to spam the list with this slightly unrelated APC stuff. It looks like there has been a fix for the dying children problem, see https://bugs.php.net/bug.php?id=62996 ... at least for occasions when this was independent of itk. (I think nobody has shown yet that is has to do anything with itk.) On 12/05/2012 04:49 PM, Peter Thomassen wrote: > Hi, > > I also see this issue with APC + itk in a bit less than 0.1% of the > requests to .php files. > > I recently switched to XCache due to another issue I was experiencing > (APC cache was occasionally corrupted for Joomla installations). > > So far, with XCache everything is fine. > > Best, > Peter From gianluca at thirdeye.it Wed Dec 5 16:55:48 2012 From: gianluca at thirdeye.it (Gianluca Zamagni) Date: Wed, 5 Dec 2012 16:55:48 +0100 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BF6D9B.1030707@a4a.de> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> <50BF6D04.2040802@a4a.de> Message-ID: <50BF7517.2050200@13fr.com> Hi, I also use itk with xcache. since version 3, you can easily have protected cache by user (using the new namespace feature) Namespace have two level, hard (set at config level, php.ini or apache php_admin) and soft = userspace. Namespace can be "auto set" based on the userid (or gid) of the process, a $_server[] value, or a constant string from config. more info here: http://xcache.lighttpd.net/ticket/287#comment:13 .?Z Hg. > Hi, > > I also see this issue with APC + itk in a bit less than 0.1% of the requests to .php files. > > I recently switched to XCache due to another issue I was experiencing (APC cache was occasionally corrupted for Joomla installations). > > So far, with XCache everything is fine. > > Best, > Peter > > On 12/05/2012 04:41 PM, Gianluca Zamagni wrote: >> >> Il giorno 05/dic/2012, alle ore 16:39, "Steinar H. Gunderson" >> > ha scritto: >> >>> On Wed, Dec 05, 2012 at 01:30:49PM +0300, Dzianis Kahanovich wrote: >>>> Thanks, good. But after day of work with pthread mutexes I got >>>> multiple "child >>>> died with signal 11" and even cron's restart. >>> >>> If cron restarts, that's probably an issue with cron, not with >>> pthreads. :-) >> >> I thinks that he mean that when Apache's child died from signal 11 he >> restart the webserver with a cron script (that I'd like to see), and not >> that the crond die. >> >> Actually I've checked some logs and I see the same child diying. I use >> APC too. >> >> Gianluca >> -- >> UNIX Sysadmin - Apple ACTC ACDT ACHDES ACTC Certified >> ? Third Eye Consulting di Zamagni Gianluca ? >> em at il. info at thirdeye.it - tel. 3288242325 >> * >> * >> * >> SAVE PAPER*think before print this email >> >> >> >> _______________________________________________ >> mpm-itk mailing list >> mpm-itk at err.no >> http://lists.err.no/mailman/listinfo/mpm-itk >> > From mahatma at bspu.unibel.by Thu Dec 6 14:01:53 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Thu, 06 Dec 2012 16:01:53 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <20121205153911.GA30045@uio.no> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> Message-ID: <50C09741.6060502@bspu.unibel.by> Steinar H. Gunderson ?????: > On Wed, Dec 05, 2012 at 01:30:49PM +0300, Dzianis Kahanovich wrote: >> Thanks, good. But after day of work with pthread mutexes I got multiple "child >> died with signal 11" and even cron's restart. > > If cron restarts, that's probably an issue with cron, not with pthreads. :-) There are my English... ;) In cron I restart apache if last N messages (not lookup now precise script logic) is "child dies with signal 11". In other words, sometimes "child died" is not fatal for whole system, but sometimes this is "avalanche". Now it was "avalanche". > If a child dies with signal 11, you should probably try to get a backtrace. > The Apache wiki has more information: May be, but I lazy prefer to use eaccelerator now. May be, once eaccelerator will be outdated for current PHP again, I will try to use APC (again)... ;) With eaccelerator I have absolutely no errors. Even I remember third-party tests - eaccelerator is faster. Just APC is near "mainstream". Just strange: people say have no this problem... > http://httpd.apache.org/dev/debugging.html > >> But it may be result of "my vfork()" (CLONE_VFORK here). > > Note that vfork() is really only ever intended to be followed by execve() > (or _exit()). vfork is not problem. Just it source of much more "child died", but without it it happened too. Early just with vfork it was completely not working, but without - just sometimes (once per week?) apache was restarting via cron script and everytime "child died" message, but not too much. -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From mahatma at bspu.unibel.by Thu Dec 6 14:27:50 2012 From: mahatma at bspu.unibel.by (Dzianis Kahanovich) Date: Thu, 06 Dec 2012 16:27:50 +0300 Subject: [mpm-itk] apc cache ("answer" after long time) In-Reply-To: <50BF6D9B.1030707@a4a.de> References: <50BCE4E5.1010801@bspu.unibel.by>

<50BE1E0E.2050104@bspu.unibel.by> <20121204161603.GB9771@uio.no> <50BF2259.2040009@bspu.unibel.by> <20121205153911.GA30045@uio.no> <8A885A48-1763-4697-8CAE-EA8E0B8A7197@thirdeye.it> <50BF6D04.2040802@a4a.de> <50BF6D9B.1030707@a4a.de> Message-ID: <50C09D56.70100@bspu.unibel.by> Fixed "in latest release"? :) Oh, no, not panish system again now. Problem last seen on PHP 5.4.8 ("Released: 18 Oct 2012"), APC from git. I can upgrade to 5.4.9, but no more tests now. Peter Thomassen ?????: > Sorry to spam the list with this slightly unrelated APC stuff. It looks like > there has been a fix for the dying children problem, see > https://bugs.php.net/bug.php?id=62996 > ... at least for occasions when this was independent of itk. (I think nobody has > shown yet that is has to do anything with itk.) > > On 12/05/2012 04:49 PM, Peter Thomassen wrote: >> Hi, >> >> I also see this issue with APC + itk in a bit less than 0.1% of the >> requests to .php files. >> >> I recently switched to XCache due to another issue I was experiencing >> (APC cache was occasionally corrupted for Joomla installations). >> >> So far, with XCache everything is fine. >> >> Best, >> Peter > > _______________________________________________ > mpm-itk mailing list > mpm-itk at err.no > http://lists.err.no/mailman/listinfo/mpm-itk > -- WBR, Dzianis Kahanovich AKA Denis Kaganovich, http://mahatma.bspu.unibel.by/ From thomas.plant at web.de Tue Dec 11 09:32:47 2012 From: thomas.plant at web.de (Thomas Plant) Date: Tue, 11 Dec 2012 09:32:47 +0100 Subject: [mpm-itk] Message in error_log: (No info could be read for "-p": geteuid()=48 but you should be root.) Message-ID: <50C6EFAF.7010409@web.de> Hello. We have installed on our Centos 6 x86_64 the httpd-itk package. Everything is working as expected, only the following entry in the apache error log irritates me: (No info could be read for "-p": geteuid()=48 but you should be root.) Should i set the Apache/Httpd Daemon 'User' and 'Group' as 'root' in httpd.conf? The installed package has the following version info: Name : httpd-itk Relocations: (not relocatable) Version : 2.2.22 Vendor: Fedora Project Release : 6.el6 Build Date: Sat 07 Apr 2012 01:47:45 PM CEST Thanks, Thomas From sgunderson at bigfoot.com Mon Dec 31 01:26:38 2012 From: sgunderson at bigfoot.com (Steinar H. Gunderson) Date: Mon, 31 Dec 2012 01:26:38 +0100 Subject: [mpm-itk] New mpm-itk release for 2.4 and trunk: 2.4.4-03 Message-ID: <20121231002638.GA32355@uio.no> Hi, At the end of the year comes a minor update to the 2.4.4 series; it has a single fix that was discussed back here in April, so I thought it would be nice to get it in. From the changelog: mpm-itk 2.4.4-03, released 2012-12-31: - Call ap_close_listeners() right after forking. This makes sure a runaway/rogue process cannot keep the server from restarting, or worse, call accept() on the listening socket. As always, http://mpm-itk.sesse.net/ has the download link. Have a happy and safe celebration :-) /* Steinar */ -- Homepage: http://www.sesse.net/