barfoo.org – BAFM

Recent downtime

November 28, 2012November 28, 2012 Christian Leave a comment

Well, you might have noticed that barfoo.org hasn’t been available for the last week or so … I had to change the DNS provider (thanks at this point again to Bene from xnull.de for putting me up as long as he did).

Sadly my new provider, when purchasing the domain hosting, doesn’t allow sub-domains. So after opening a service ticket with them, they switched me into a webhosting contract which allows sub-domains (wtf…).

And since today, everything should be available again. If you notice something missing/not working give me a holler.

Setting up a phpMyAdmin auto-update

May 4, 2012May 4, 2012 Christian 1 Comment

Well, just like everybody else, I’ve been using phpMyAdmin to do my casual MySQL fixing/work on this website. However, recently the phpMyAdmin developers switched to Git on SourceForge and then to GitHub shortly after that.

So, the guy over at Network Jack wrote down what I had already been doing:

git clone --depth=1 git://phpmyadmin.git.sf.net/gitroot/phpmyadmin/phpmyadmin
cd phpmyadmin
git checkout --track -b PMASTABLE origin/STABLE

git clone --depth=1 git://phpmyadmin.git.sf.net/gitroot/phpmyadmin/phpmyadmin

cd phpmyadmin

git checkout --track -b PMASTABLE origin/STABLE

However, as I said before, they switched from SourceForge to GitHub, thus you need another URL.

git clone --depth=1 git://github.com/phpmyadmin/phpmyadmin.git
cd phpmyadmin
git checkout --track -b PMASTABLE origin/STABLE

git clone --depth=1 git://github.com/phpmyadmin/phpmyadmin.git

cd phpmyadmin

git checkout --track -b PMASTABLE origin/STABLE

After that, you just need to add a simple cronjob that enters the directory and runs git pull.

Blog is back!

September 30, 2010September 30, 2010 Christian Leave a comment

As you can see, the blog is finally back! I haven’t been visiting the blog on a daily basis (actually, I haven’t been here for some time), so it apparently took me ten days to figure that the wp_posts table of my wordpress installation was marked as crashed.

To repair that, I had to take down the MySQL instance and use myisamchk on the .MYI file. Once again, it’s back now, only one draft has disappeared into thin air (well, that ain’t so bad), but that’s a minor loss.

I still have some stuff I wanna share, but that needs me to be at work (which I obviously ain’t right now, hehe). So I guess either tomorrow or on Saturday (which I’m at work — again!), I’m gonna draft up some of the stuff I’ve been meaning to publish … maybe 🙂

My neverending lighttpd troubles

July 16, 2009August 8, 2014 Christian Leave a comment

Well, after a day or so my lighttpd troubles reappeared. But this time, the lighttpd process would simply put out this:

(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

(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.

  "max-procs"         =&gt; 2
  "idle-timeout"      =&gt; 20,
  "socket"            =&gt; "/tmp/php.socket-" + var.PID,
  "bin-path"          =&gt; "/usr/bin/php-cgi",
  "bin-environment"   =&gt; ( "PHP_FCGI_CHILDREN" =&gt; "6",
                           "PHP_FCGI_MAX_REQUESTS" =&gt; "7000" )

"max-procs" => 2

"idle-timeout" => 20,

"socket" => "/tmp/php.socket-" + var.PID,

"bin-path" => "/usr/bin/php-cgi",

"bin-environment" => ( "PHP_FCGI_CHILDREN" => "6",

"PHP_FCGI_MAX_REQUESTS" => "7000" )

Up till now (I made the change on July 14th), these changes seem to have fixed the issue, guess I’m still hoping (with the saying “Hope dies last” in mind) it’s gonna fix my problems once and for all.

Lighttpd issues

July 11, 2009August 8, 2014 Christian 1 Comment

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.

*/15 * * * * root    /etc/init.d/lighttpd restart &amp;&gt;/dev/null

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.

So the thank you is probably to the one, who introduced those lines to the ca-certificates ebuild (guess, that would be vapier, the old code monkey):

  if [[ $badcerts -eq 1 ]]; then
    ewarn "You MUST remove the above broken symlinks"
    ewarn "Otherwise any SSL validation that use the directory may fail!"
    ewarn "To batch-remove them, run:"
    ewarn "find -L ${ROOT}etc/ssl/certs/ -type l -exec rm {} +"
  fi

if [[ $badcerts -eq 1 ]]; then

ewarn "You MUST remove the above broken symlinks"

ewarn "Otherwise any SSL validation that use the directory may fail!"

ewarn "To batch-remove them, run:"

ewarn "find -L ${ROOT}etc/ssl/certs/ -type l -exec rm {} +"

After letting the find run through /etc/ssl/certs and restarting lighttpd in the process, everything is back to working order! Finally!

Lighttpd troubles resolved

June 28, 2009August 8, 2014 Christian 1 Comment

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 ….

Weird lighttpd troubles

June 17, 2009June 17, 2009 Christian 1 Comment

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, it seems like lighttpd is getting stuck in mod_fastcgi …

2009-06-23 21:34:40: (mod_access.c.135) -- mod_access_uri_handler called
2009-06-23 21:34:40: (mod_fastcgi.c.3675) handling it in mod_fastcgi
2009-06-23 21:34:40: (mod_fastcgi.c.3005) got proc: pid: 11151 socket: unix:/var/run/lighttpd/lighttpd-fastcgi-php-11147.socket-0 load: 85

2009-06-23 21:34:40: (mod_access.c.135) -- mod_access_uri_handler called

2009-06-23 21:34:40: (mod_fastcgi.c.3675) handling it in mod_fastcgi

2009-06-23 21:34:40: (mod_fastcgi.c.3005) got proc: pid: 11151 socket: unix:/var/run/lighttpd/lighttpd-fastcgi-php-11147.socket-0 load: 85

Usually the last line is followed by a line telling that it released the proc, but not always.