PHP/Recode fail

I use PHP on FreeBSD servers, compiled from the ports system. It works very well, except that sometimes… well… sometimes… segfaults happen. Yes random, bizarre, “how did this working system suddenly become non-working wtf” errors happen.

Here’s an example of what happened to me today. This is a snip from my lighttpd error log

(mod_fastcgi.c.2722) child signaled: 11
(mod_fastcgi.c.1051) the fastcgi-backend /usr/local/bin/php-cgi failed to start:
(mod_fastcgi.c.1065) terminated by signal: 11
(mod_fastcgi.c.1070) to be exact: it segfaulted, crashed, died, … you get the idea.
(mod_fastcgi.c.1072) If this is PHP, try removing the bytecode caches for now and try again.
(mod_fastcgi.c.2759) ERROR: spawning fcgi failed.


Well in a nutshell, php-cgi is failing to start. When I attempt to run /usr/local/bin/php-cgi from the command line, it causes a segmentation fault. If you’ve seen this before, you might have thought “oh no… sig11! signal 11 could mean my hardware is fried!” At least I thought so. The truth of the matter, in this case, is that the php-cgi executable is not happy. Why isn’t it happy? I’m glad you asked. We all want our executeables to be happy, right?

This wasn’t easy for me to figure out the first time it happened to me last year. I was going nuts trying to figure out what went wrong, I even put in a request for new hardware (yes a new development server, which I actually got). This didn’t solve my problem either. I began to panic. I’m not sure what made me think of it, but after a while I decided to try minimalizing my PHP installation, by commenting out extensions from my extensions.ini file (on my sys it’s /usr/local/etc/php/extensions.ini)

With everything commented out, php-cgi was happy again, but of course I need at least a few of the extensions (specifically mysqli), and so I started adding extensions back in one at a time to find the problem. It turns out that the problem is with the recode extension.

With the recode extension out of the picture, things went along fine for quite a while and I was able to develop my small web application with Zend Framework (1.5 at the time, I think). PHP was happy, Lighttpd was happy, I was happy. There was a lot of happiness to be found! And then it happened. I updated my PHP port with portmaster. A dark cloud (a cloud named sig11) loomed over the server and the happiness turned to confusion once again. Then I remembered… “didn’t this happen last year?” Yes. Yes it did. Same problem. This time I didn’t panic though, I went straight for the extensions file.

Now I’m not sure what about the recode extension my system doesn’t like, but it doesn’t like it. It didn’t like it last year, and it doesn’t like it now. The PHP port installed a new copy of extensions.ini which includes the recode extension and so that’s why the error reoccured after updating the port. If you are experiencing weird segmentation faults with PHP, I highly recommend you start commenting out your extensions. Also, you may want to check the order of the extensions. If they are in alphabetical order, something is wrong. Some extensions rely on others to be loaded first, so be careful.

That’s it for now… PHP is happy once again, and I’m working on a new dev project, this time with Zend Framework 1.7  🙂 I’d tell you more about it… but it’s a secret. No, really, it’s a secret.

X11 Forwarding via SSH from OpenBSD 4.4 to OS X 10.5.5

Does it work? The answer is yes! 🙂
All you have to do is edit the sshd_config file on the OpenBSD machine and set X11Forwarding to yes, then fire up X (I’m using XQuartz 2.3.2 (xorg-server 1.4.2-apple18)) and in an xterm (or!) enter

ssh -Y user@openbsd_machine program

P.S.: Actually, you don’t even have to start X on either end of this connection, it will still work. I just tried 🙂

The Latest Reason I Hate Windows Server

Why can’t I just reboot? Why do I have to choose some option from a dropdown? I only wanted to reboot! Now I was tricked into shutting down a server that isn’t even in the same zipcode! What the hell Microsoft? Why couldn’t you make reboot the first choice? Now I’m stuck making calls and e-mailing people to say “sorry I was confused by the crazy windows shutdown options”. Shutting down should be easier. Instead, the first thing you have to do is click START, which makes NO SENSE WHATSOEVER, then you have to choose from some silly dropdown to explain why. I’ll tell you why I was rebooting Microsoft! I’ll tell you why! It’s because you force me to reboot in order to get anything done! that’s why! That’s why I have to reboot the damned server! WTF?! You make my life miserable at every opportunity. Is it because you know I hate you? Is it because you know I’m using a mac and have a FreeBSD machine and OpenBSD machine at home? is that it? Is it because you know about my Ubuntu desktop machine? What is it? Why must you torture me this way?

So about that Golden Apple Project of mine…

I was just looking through my archives and remembered the Golden Apple Project. Ahhh yes. Well it turns out that the machine was so old it just stopped working altogether. OpenBSD was running just fine on it, but after a year the network card died and when I tried to add a netgear PCI NIC it caused kernel panics. I do have a new apple PPC machine that I have been prepping to handle light duties, her name is aphrodite and she’s a little red iMac. It’s my hope that I can keep at least one PPC box running unix in my little computer family…

ISC DHCPD duplicate uid lease

Ever see this?

dhcpd: uid lease for client xx:xx:xx:xx:xx:xx is duplicate on 192.168.1/24

or something like it, in your dhcp logs? Well I checked /var/log/messages today and saw that I had thousands of this message repeated over and over (so much so it was spamming my log  and making it harder to find what might be important stuff). I searched around the ‘net and found some hints but nothing conclusive. The hints pointed toward a duplicate lease (duh) but more specifically lead me to check my leases file. Mine was located in /var/db/dhcpd/dhcpd.leases.

It turns out that what caused this error for me was that I had started the machine in question (the MAC address has been altered to protect the innocent haha) before I had the time to create a reservation for it. Then after it already had an address leased to it, I created a reservation for it (for internal DNS purposes, nothing more). Apparently because duplicates are allowed by default in isc dhcpd, when the machine’s networking was restarted and it got it’s new reserved IP, the server kept the original lease (which was that .150 address) and also got a lease from it’s reservation (.80 on my network). Since the .150 lease was still present in the leases file it caused the warning message (over and over and over for a month).

So if you are using isc dhcpd, and you use reservations, and you’re getting these error messages, you might want to check your leases file and make sure that you don’t have a lease for something that also has a reservation under a different IP.

The other pages I found on my search also suggested that you might have a reservation that hands out an address that is within your dynamic scope. You definitely don’t want to do that, so you may need to check that out as well in your dhcpd.conf.

For the curious, I run FreeBSD 7 on a Pentium 4 Dell desktop (I think it’s a dimension series, I haven’t looked at it in a while haha) that sits in my kitchen as a headless DNS/DHCP/Web/Random Unix Fun server. It’s actually making lots of bad noise lately and I think one of it’s fans might be going 🙁 I’ll check that out and report back 🙂