Well, since about a week or so I keep having troubles with my vHost and lighttpd. The point being, after some time (up till now it’s been something between days and minutes) lighttpd completely freezes and doesn’t serve no content anymore. I don’t know if this is related to PHP (might be, I did perform an update to dev-lang/php-5.2.9-r2 on Thu May 28 12:18:57 2009), but I have to figure this out since the restart cron-job is getting annoying. ...
Well, after last weeks lighttpd troubles with PHP (or was it without ?), they finally seem resolved. First thing I did, was upgrade to the new php-version (5.2.10). After that, I ran revdep-rebuild, which apparently found issues with lighttpd being linked to a wrong pcre-version. After remerging lighttpd the issues seem to be gone! Well, guess I was to quick in saying the problem was resolved .. it’s still there, just not happening as fast as it would in the past ….
At first, it seemed that my lighttpd issues were resolved by updating PHP/remerging lighttpd. But apparently not. After putting in a crontab entry, that restarts lighttpd every 15 minutes (which completely sucks), the issue was minimized in it’s impact but not really solved. 1 */15 * * * * root /etc/init.d/lighttpd restart &>/dev/null Thanks to Michél (I guess, again) – who helped me looking at the strace logs, and of course Christian (aka hoffie – one of my old Gentoo buddies), the issue seems finally resolved. It turns out it was neither a PHP nor lighttpd issue. It was a simple matter of (stale) symlinks in /etc/ssl/certs if you can imagine that. Apparently a stale symlink forced PHP into a loop or something, from which it couldn’t recover on it’s own. ...
Well, after a day or so my lighttpd troubles reappeared. But this time, the lighttpd process would simply put out this: 1 2 3 4 (mod_fastcgi.c.2913) backend is overloaded; we'll disable it for 2 seconds and send the request to another backend instead: reconnects: 0 load: 131 (mod_fastcgi.c.2668) fcgi-server re-enabled: 0 /var/run/lighttpd/lighttpd-fastcgi-php-17242.socket (mod_fastcgi.c.2913) backend is overloaded; we'll disable it for 2 seconds and send the request to another backend instead: reconnects: 0 load: 131 (mod_fastcgi.c.2668) fcgi-server re-enabled: 0 /var/run/lighttpd/lighttpd-fastcgi-php-17242.socket And as the message says, PHP (or rather mod_fastcgi?) would simply stop to process requests. In the end, I tuned some of the lighttpd/mod_fastcgi parameters. ...
Well, I happen to be back at my favorite application. Today I stumbled upon a " nice" thing. If you turn on the Zend Optimizer (doesn’t matter whether it is 2.6.2 or 3.3.0), one of the TYPO3 back ends ain’t showing any content in the preview pane. Once you turn the Zend Optimizer stuff off, it works without a problem. O RLY ? And as Zend stated on their " Support Forum", they don’t really support the Zend Optimizer stuff in the first place. Which is nice, what for do you need the Zend Guard shit in the first place ?? ...
Apparently the TYPO3 version we are using, doesn’t play too nice with the MySQL MasterMaster replication. Sometimes, something like this is going to happen: 1 2 070826 0:44:32 [ERROR] Slave: Error 'Duplicate entry '75-222419149' for key 1' on query. Default database: 't3nb'. Query: 'INSERT INTO cache_pagesection 070826 0:44:32 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'dbc-mysql1.000192' position 611861372 Well, as you can see from the last line in the log, the Slave-SQL thread found a duplicate entry and thought it is smart to just turn off the thread instead of disregarding the just made entry. So from now on, both databases drift since there ain’t no replication anymore until someone kick starts the replication again (someone being me). ...
What would you figure from the above ? Hopefully the rather obvious, that it’s a really shitty combination. So we figured it would be a nice thing to test our new setup before going into pre-production testing or production, but we don’t have an extra spare box. So we took one of the power4 boxes we have mounted in the rack basically consuming energy all day (that’s about 38kWh a day) and installed SLES10 onto it. Which wasn’t all that bad (at first the box repeatedly started back to AIX, from CD and after convincing the SMS - that’s basically the bios on the power*-boxes also known as System Management Services with a hammer to boot from the first hard disk). ...