[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Building my own Perl on Sarge AMD64

Hi all,

I am using Sarge on AMD64 (dual Opteron). I noticed recently that there were some issues with the stock version of Perl - "v5.8.4 built for x86_64-linux-thread-multi". Messages were appearing in my apache error log every time a child process terminated, to the effect that "2 or more threads are running". I wasn't starting multiple threads, so this always mystified me. At the same time, I was noticing that at times of higher webserver load, the CPU "system" load and fork rates were spiking unreasonably (going to over 120 forks per second). I had a suspicion about the multithreaded perl, as I had never seen this before on my previous servers, which had the same software setup (2.6 kernel, apache 1.3.x), except that they had had non-multi-threaded Perl installed.

I am no expert on debian packages, and I couldn't find any references on the Web for either getting pre-built non-threaded Perl, or how to build a debian package for it. The process for getting Perl 5.8.8 from unstable or testing scared me, because it seemed that the package had dependencies that would mean a whole lot of other stuff might need to also be upgraded. Also, I assume that the newer versions would also be multithreaded, which wouldn't help all that much if threading is the problem. I don't really fancy upgrading a lot of core packages to testing or unstable on my production server, which is unfortunately the only AMD64 (or debian for that matter) box I have access to. My workstation is slackware.

So I decided to try building my own non-threaded Perl, from source. I got the source for 5.8.8 from perl.org, and it built ok as non-threaded, and I was able to get apache with mod_perl built using it. I also had to re-build all my perl modules, but that was ok. The thread error messages disappeared from the apache logs, and munin now shows that the CPU spikes have all but disappeared (you can still see a rise in CPU usage and forkrate when the web traffic increases, but it is nothing like the spikes we had before). So I guess this helped fix the problem, for whatever reason.

However I quickly discovered that by replacing the Debian Perl with my own, it broke a bunch of stuff, such as apt-get. I got all kinds of errors because things like deb-conf appeared to now be broken with the new perl. I couldn't find out easily what was missing - no reference to deb-conf or the other stuff that was missing on CPAN, and Debian itself seemed to be very confused because it thought its Perl should be there, but it wasn't.

I tried removing the Debian version of Perl, to make it cleaner so that the new one was the only version lying around, but quickly discovered that dozens of other packages depend on it - I would end up also removing all manner of essential utilities. So I obviously have to leave the Debian Perl in place.

I ended up building apache with my new perl, but then afterward re-instated the /usr/bin/perl with the old version. This appeared to make everything work again with apt-get, but my apache is still using the newer version. I don't like this, it seems very kludgy and rickety - when I need to build apache again, I'll have to remember to temporarily re-instate my new version during the build.

Obviously there are issues with building your own perl, but I'm sure it must be possible to do it using the "official Debian way". Can anyone give me a step-by-step instructions on how you're supposed to build your own Perl on a Debian system, while still keeping everything happy?



Reply to: