All posts tagged apache

Memory leaks caused by PHP are hard to pinpoint. My server started crashing regularly, out of memory from running WordPress on Apache22 and FreeBSD. It happens especially when posting, but also at random times. I tried disabling plugins, changing the theme, to no avail. There might be more than one faulty script, and there is little hope to find these leaks. Hopefully they will be plugged in future releases. In the mean time, I wrote a Python script that checks memory status and restarts Apache if needed. Placed on a cron job, it runs every ten minutes on my server.:

It is a temporary fix, but it works. Her is my /etc/crontab line:
*/0 * * * * root /usr/local/bin/python /home/gil/scripts/mleaks.py

Good luck!

It doesn’t take more than one directory on your web server with write permissions to let someone in.. I started to notice Perl processes running under the www user on my server. It was taking a lot of the CPU, and I couldn’t find the culprit. The only thing I could do was shutting down the Apache web server, then killing the www processes: kill -9 -uwww. But then, it would restart later. So, I looked in the most likely directory /tmp for suspicious files. There were… Perl scripts disguised as images or txt files. It was an Indonesian IRC bot. I removed the files, wondering how they got into /tmp.

The next day, the offending processes resumed! There had to be some other malicious Perl script somewhere. I did a grep -R /usr/bin/perl /home. To locate all files chmoded 777, I tried find /home -type d -perm 777. One of my users was running OSCommerce, and had the images directory chmoded to 777. Ha! The directory was full of exploit files owned by the www user. I deleted them and chmoded the directory to 755. Hopefully that will be the end of it. I will keep a close eye on server processes and any new files owned by www, or containing Perl code.

Any suggestion would be appreciated on how to avoid future problems. I strongly encourage anyone managing a server to check their permissions, and look for Perl scripts that shouldn’t be there.

I have installed GD a few times before, and never cam across this problem, maybe I was just lucky. I installed ImageMagick, GD and JPEG on the machine, a FreeBSD 7.1-RC2 server running Apache 1.3.41 and PHP 5.2.11.

  • /usr/ports/graphics/gd
  • /usr/ports/graphics/ImageMagick
  • /usr/ports/graphics/jpeg

That was easy, just “make install clean” and you’re in business..

Then, I proceeded to recompile PHP:

./configure –with-mysql –with-apxs=/usr/local/sbin/apxs –with-pcre-regex –enable-mbstring=en –with-zlib –with-gd –with-jpeg

Ah, problem.. “–with-jpeg” is not recognized. I don’t care about PNG support, since it is included in GD by default. After a bit of research, I find out that I need to add the path to the jpeg library:

./configure –with-mysql –with-apxs=/usr/local/sbin/apxs –with-pcre-regex –enable-mbstring=en –with-zlib –with-gd –with-jpeg-dir=/usr/lib

Now the output of phpinfo() shows my option, but scrolling down to the GD info box, I don’t see JPEG enabled there, crap! So, I try a few locations for the jpeg library, /usr, /usr/local, /usr/local/lib.. Same result. It should be /usr/lib.. Am I forgetting something? Well, yes, the problem has to be related to the path..

Then it hits me! I didn’t do a “make clean” before reconfiguring.. I try that, bingo! Jpeg enabled!

Good luck with your installation 🙂