All posts tagged freebsd

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/

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 my aviation site Planenews on a FreeBSD server. As traffic increased, I was getting more database errors. Looking around the web for clues, I discovered that FreeBSD did not have a default my.cnf file in /usr/local/etc. You can find sample files in /usr/local/share/mysql. I used my-huge.cnf, renamed it to my.cnf, put it in /usr/local/etc, et voila (don’t forget to restart MySQL)!

Problem solved? Nope.. I was still getting errors at peak traffic. I then found mysqltuner, a Perl diagnosis tool for MySQL. I was missing a few variables in my.cnf. See the file below, and notice the additions under “Added by Gil.”

# The following options will be passed to all MySQL clients
#password       = your_password
port            = 3306
socket          = /tmp/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
port            = 3306
socket          = /tmp/mysql.sock
key_buffer = 384M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 128M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4

# Added b Gil:
# max_connections 250 crashes my server, use with caution..
#max_connections = 250
wait_timeout = 180
interactive_timeout = 45
tmp_table_size = 64M
max_heap_table_size = 32M

# Disable Federated by default

# Replication Master Server (default)
# binary logging is required for replication

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id       = 1

# Point the following paths to different dedicated disks
#tmpdir         = /tmp/
#log-update     = /path-to-dedicated-directory/hostname

max_allowed_packet = 16M

# Remove the next comment character if you are not familiar with SQL

key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

key_buffer = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M


The site seems to be running fine now, with no errors. I guess I will have to wait for a story to make it to a major social networking site to see if it really can take a heavy load. Please tell me about your optimization tips, and how you prepared for traffic spikes…

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 🙂