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
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: email@example.com — Headers: Date: Mon, 26 Dec 2016 06:55:17 +0000 From: Joe Smith <firstname.lastname@example.org> Message-ID: <email@example.com> 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.
The following command will list all the open tcp and udp connections
netstat -anp --tcp --udp
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
Empty an in-use nohup.out file
cat /dev/null >nohup.out
If the file is not in use, the following works in bash
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
Do you have threads locked in a state that looks like this?
at java.lang.Object.wait(Native Method)
- waiting on <26457185> (a java.util.HashMap)
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: http://wiki.zimbra.com/wiki/Configuring_for_IPv4