Find which PHP script is sending spam emails

You have a WordPress blog that has been compromised or hacked. Some script on the server is sending spam emails and you do know which one. Try the following steps to find and remove the bad script.

1. Create a file called phpmail.log

touch /var/log/phpmail.log

2. Change permissions on the file so that the web server can write to it. This can be done in many ways.

chown httpd:httpd /var/log/phpmail.log


chmod 777 /var/log/phpmail.log

3. Locate your php.ini file (in case of RHEL, CenOS and SuSE, it will here: /etc/php.ini). Edit/add the following two lines are in file

mail.add_x_header = On
mail.log = /var/log/phpmail.log

4. Restart your web server

service httpd restart

5. Now tail the log file…

tail -f /var/log/phpmail.log

When an email is sent from a PHP script you will see an entry in the log that looks like this…

mail() on [/var/www/html/site2/wp-content/plugins/wp-image-hover-lite/admin/functions.php(1967) : eval()’d code:775]: To: — Headers: Date: Mon, 26 Dec 2016 06:55:17 +0000 From: Joe Smith <> Message-ID: <> X-Priority: 3 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=”b1_5cd2be098536da5aefaba80101b8a1a3″ Content-Transfer-Encoding: 8bit

In this case the offending script can be seen in bold above. Check out this script and delete it if it looks suspicious.

Linux: Which directory has the most files?

An inode is used for every file in the filesystem. If the system is running out of inodes that means there are some directories with a lot of files in them.

The following command will find the directories with most files.

find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

The following command list free inodes on all filesystems

df -hi


Linux: Clear contents of a file

Empty an in-use nohup.out file

cat /dev/null >nohup.out


If the file is not in use, the following works in bash

> foo.log

The command above empties out the file foo.log

If sudo is needed, truncate can be used as well

sudo truncate -s 0 foo.log

-s is the size option. 0 in this example sets the size to 0 bytes

JVM threads getting locked when using IPv6 methods with IPv4 address

Do you have threads locked in a state that looks like this?

java.lang.Thread.State: WAITING
at java.lang.Object.wait(Native Method)
- waiting on <26457185> (a java.util.HashMap)
at java.lang.Object.wait(

This usually happens when the applications trying to use IPv6, when the environment is really only configured for IPv4.

The solution is to configure the the Java processes to prefer the IPv4 stack. The default is to prefer the IPv6 stack. This can be done by specifying a JVM argument to prefer IPv4.

A detailed explanation of this problem can be found here: