How do I determine what version of the Linux kernel my system is running?
The command uname -a will tell you the system defined kernel name, hostname, kernel version, hardware name, processor type, hardware platform and operating system name. Executing a uname -r will tell you just the kernel version. Run a ‘man uname’ for specifics.
Wednesday, March 5, 2008
How to Log Slow MySQL Queries
Create a log that shows slow MySQL queries
This process will create a log file that will show you any queries taking longer than normal. Read the steps, then copy and paste the commands one at a time.
1) Create the folder /home/mysqllogs. Chown it to mysql:mysql
mkdir /home/mysqllogs
chown mysql:mysql /home/mysqllogs
2) Edit the /etc/my.cnf file.
nano /etc/my.cnf
* Add the following line under the [mysqld] header:
log-slow-queries = /home/mysqllogs/slow_queries.log
3) Restart MySQL? services
service mysql stop
service mysql start
This process will create a log file that will show you any queries taking longer than normal. Read the steps, then copy and paste the commands one at a time.
1) Create the folder /home/mysqllogs. Chown it to mysql:mysql
mkdir /home/mysqllogs
chown mysql:mysql /home/mysqllogs
2) Edit the /etc/my.cnf file.
nano /etc/my.cnf
* Add the following line under the [mysqld] header:
log-slow-queries = /home/mysqllogs/slow_queries.log
3) Restart MySQL? services
service mysql stop
service mysql start
Setting the Time in Linux
Setting the Time in Linux
A consistently accurate server clock is vital to the sanity of many applications that are supported by an Apache webserver environment. Fortunately, there are a number of different ways to set the date/time in any version of linux. The main thing to keep in mind is that linux keeps two separate times - software (system) time, and the hardware clock. Let's take a look at a great way to get everything synced and correct... shall we?
Yes, let's.
Configuration
Copy the file that represents the desired timezone from /usr/share/zoneinfo/ to /etc/localtime.
For example:
cp /usr/share/zoneinfo/GMT /etc/localtime
Modify the settings in /etc/sysconfig/clock using your favourite text editor.
Example:
ZONE="GMT"
UTC=true
ARC=false
Note: You can find all possible ZONEs by listing the contents of /usr/share/zoneinfo/.
Feel free to sync the time against a time server, and add an entry to the crontab to do the same.
Here's an example using cPanel's time server:
/usr/bin/rdate -s httpupdate.cpanel.net
crontab -e
0 0 * * 6 /usr/bin/rdate -s httpupdate.cpanel.net
Now that the system time is correct, sync the hardware clock against the system time:
(Notice the similarities between "systohc" and "system to hardware clock")
/sbin/hwclock --systohc
Testing
You can test the results in a few different ways:
root@server [~]# date
Fri Jul 28 17:05:08 CDT 2006
root@server [~]# clock
Fri 28 Jul 2006 05:05:10 PM CDT -0.033127 seconds
root@server [~]#
You can also test by writing a php script that prints the time:
root@server [~]# cat test.php
print( date("D M j G:i:s Y") . "\n" );
?>
root@server [~]# php test.php
Fri Jul 28 17:08:12 2006
root@server [~]#
A consistently accurate server clock is vital to the sanity of many applications that are supported by an Apache webserver environment. Fortunately, there are a number of different ways to set the date/time in any version of linux. The main thing to keep in mind is that linux keeps two separate times - software (system) time, and the hardware clock. Let's take a look at a great way to get everything synced and correct... shall we?
Yes, let's.
Configuration
Copy the file that represents the desired timezone from /usr/share/zoneinfo/ to /etc/localtime.
For example:
cp /usr/share/zoneinfo/GMT /etc/localtime
Modify the settings in /etc/sysconfig/clock using your favourite text editor.
Example:
ZONE="GMT"
UTC=true
ARC=false
Note: You can find all possible ZONEs by listing the contents of /usr/share/zoneinfo/.
Feel free to sync the time against a time server, and add an entry to the crontab to do the same.
Here's an example using cPanel's time server:
/usr/bin/rdate -s httpupdate.cpanel.net
crontab -e
0 0 * * 6 /usr/bin/rdate -s httpupdate.cpanel.net
Now that the system time is correct, sync the hardware clock against the system time:
(Notice the similarities between "systohc" and "system to hardware clock")
/sbin/hwclock --systohc
Testing
You can test the results in a few different ways:
root@server [~]# date
Fri Jul 28 17:05:08 CDT 2006
root@server [~]# clock
Fri 28 Jul 2006 05:05:10 PM CDT -0.033127 seconds
root@server [~]#
You can also test by writing a php script that prints the time:
root@server [~]# cat test.php
print( date("D M j G:i:s Y") . "\n" );
?>
root@server [~]# php test.php
Fri Jul 28 17:08:12 2006
root@server [~]#
How to find all IPs bound to a machine that are not hosting sites
How to find all IPs bound to a machine that are not hosting sites
This command can be used to find free IPs on a non-panel Linux server.
echo System has $(ifconfig | grep "inet addr:" | grep -v 127.0.0.1 | awk '{print $2}' | sed s/"addr:"// | sort -n > /tmp/boundips && cat /usr/local/apache/conf/httpd.conf | grep ""$// | sed s/">"$// | sort -n | uniq > /tmp/usedips && diff /tmp/boundips /tmp/usedips | sed -n /^"< "/p | sed s/^"< "// | wc -l) free IPs: && diff /tmp/boundips /tmp/usedips | sed -n /^"< "/p | sed s/^"< "// && rm -f /tmp/boundips /tmp/usedips
Note: On a cPanel server, there is a tool called "Rebuild the IP address pool", which performs the same function.
This command can be used to find free IPs on a non-panel Linux server.
echo System has $(ifconfig | grep "inet addr:" | grep -v 127.0.0.1 | awk '{print $2}' | sed s/"addr:"// | sort -n > /tmp/boundips && cat /usr/local/apache/conf/httpd.conf | grep ""$// | sed s/">"$// | sort -n | uniq > /tmp/usedips && diff /tmp/boundips /tmp/usedips | sed -n /^"< "/p | sed s/^"< "// | wc -l) free IPs: && diff /tmp/boundips /tmp/usedips | sed -n /^"< "/p | sed s/^"< "// && rm -f /tmp/boundips /tmp/usedips
Note: On a cPanel server, there is a tool called "Rebuild the IP address pool", which performs the same function.
How to clean Exim's Mail queue
How to clean an Exim queue
* How to clean an Exim queue
o Using WebHost Manager
o Advanced Users
o Very Advanced Users
Using WebHost Manager
1. Login to WHM.
2. On the Main page, click on the email icon:
3. In the mail menu, select "Manage Mail Queue":
* Note: Instead of steps 2 and 3, you can select "Manage Mail Queue from the left margin:
4. Find the message you wish to delete and select "Delete":
Advanced Users
WARNING: The information below is intended for users with advanced knowledge of operating systems, control panels, and other aspects of server management. Do NOT simply copy and paste commands to resolve issues as you may severely harm your server, cause downtime, or incur billable support not covered under your DEFCON plan. Please open a support ticket if you feel uncomfortable with the suggestions provided.
There are many times when a mail queue may become filled with what is essentially junk mail. At extreme levels, this can cause high load and delayed mail delivery.
You can use a variation of the following command via a shell prompt to delete only these junk messages from the mail queue:
grep -lR KEYWORD /var/spool/exim/input/* | xargs rm -f
This will purge the mail queue of any messages that contain KEYWORD.
Any messages deleted in this manner are IRRETRIEVABLE (aka: Gone for good)
Is this dangerous? You bet it CAN be. If you have any doubts, open a support ticket.
Let's look at an example.
Imagine a case in which users are abusing a bad FormMail.pl installation on server.fastservers.net. Almost all of these messages will contain the username "nobody@server.fastservers.net". We want to delete ALL of these messages, so we would insert "nobody@server.fastservers.net" in place of "KEYWORD" in the command above.
This will delete all messages in the exim queue that contain the keyword "nobody@server.fastservers.net".
Very Advanced Users
Grep does regular expressions. This means you can catch tricky spammers with a little mind power. For example:
grep -lRP Vz*Az*Lz*Iz*Uz*M /var/spool/exim/input/* | xargs rm -f
This command will delete any message containing the letters V, A, L, I, U, M, in that order, and with 0 or more "z" characters between them. A few of the keywords it will match are listed:
VALIUM
VzALIUM
VAzLIzUzM
VALzIUM
VzALzIUM
You get the idea.
* How to clean an Exim queue
o Using WebHost Manager
o Advanced Users
o Very Advanced Users
Using WebHost Manager
1. Login to WHM.
2. On the Main page, click on the email icon:
3. In the mail menu, select "Manage Mail Queue":
* Note: Instead of steps 2 and 3, you can select "Manage Mail Queue from the left margin:
4. Find the message you wish to delete and select "Delete":
Advanced Users
WARNING: The information below is intended for users with advanced knowledge of operating systems, control panels, and other aspects of server management. Do NOT simply copy and paste commands to resolve issues as you may severely harm your server, cause downtime, or incur billable support not covered under your DEFCON plan. Please open a support ticket if you feel uncomfortable with the suggestions provided.
There are many times when a mail queue may become filled with what is essentially junk mail. At extreme levels, this can cause high load and delayed mail delivery.
You can use a variation of the following command via a shell prompt to delete only these junk messages from the mail queue:
grep -lR KEYWORD /var/spool/exim/input/* | xargs rm -f
This will purge the mail queue of any messages that contain KEYWORD.
Any messages deleted in this manner are IRRETRIEVABLE (aka: Gone for good)
Is this dangerous? You bet it CAN be. If you have any doubts, open a support ticket.
Let's look at an example.
Imagine a case in which users are abusing a bad FormMail.pl installation on server.fastservers.net. Almost all of these messages will contain the username "nobody@server.fastservers.net". We want to delete ALL of these messages, so we would insert "nobody@server.fastservers.net" in place of "KEYWORD" in the command above.
This will delete all messages in the exim queue that contain the keyword "nobody@server.fastservers.net".
Very Advanced Users
Grep does regular expressions. This means you can catch tricky spammers with a little mind power. For example:
grep -lRP Vz*Az*Lz*Iz*Uz*M /var/spool/exim/input/* | xargs rm -f
This command will delete any message containing the letters V, A, L, I, U, M, in that order, and with 0 or more "z" characters between them. A few of the keywords it will match are listed:
VALIUM
VzALIUM
VAzLIzUzM
VALzIUM
VzALzIUM
You get the idea.
How to Repair MySQL Tables
Symptoms of corrupted tables
Corrupted tables can cause a high load, or cause MySQL to crash fairly often. If you do have a problem with corrupted tables, you should see entries in the MySQL error log indicating this. The error log is usually located at /var/lib/mysql/HOSTNAME.err.
In that filename, "HOSTNAME" indicates the base hostname of your server. You can determine your server's hostname with the following command:
hostname
The most common error message in this log file that indicates you should attempt a repair on the MySQL tables is (errno: 145), but you should also attempt a repair if you see many of the following error codes: 126, 127, 132, 134, 135, 136, 141, 144
The easy way to repair
You may have a tool on your server called "mysqlcheck". If so, you can attempt an automatic repair with the following command:
mysqlcheck -A --auto-repair
The mysqlcheck tool should be run while MySQL is running. Do not stop MySQL before attempting a repair using this method.
The advanced method
WARNING: The information below is intended for users with advanced knowledge of operating systems, control panels, and other aspects of server management. Do NOT simply copy and paste commands to resolve issues as you may severely harm your server, cause downtime, or incur billable support not covered under your DEFCON plan. Please open a support ticket if you feel uncomfortable with the suggestions provided.
Read me first
Myisamchk uses /tmp while repairing, so if a table is larger than the /tmp partition, you can't repair that one with the following steps.
If you /tmp is smaller, you can repair it utilizing a temp tmp folder... something like the following:
myisamchk -r -q database/table.MYI --tmpdir=/home/tmp
Prep work
Before you start modifying tables, you should stop MySQL or you'll get a lot of false positives on the check, and a lot of problems on the repair. So before you go any further, stop MySQL. Even before that, if you have cPanel, you should first stop chkservd:
/etc/init.d/chkservd stop
Chkservd is cPanel's service monitor. It checks every eight (8) minutes to ensure all services are running, and if it detects any problems it will attempt to restart the service.
After chkservd is stopped, or if you do not have cPanel installed, stop MySQL:
/etc/init.d/mysql stop
Potential problem with myisamchk
Myisamchk uses /tmp while repairing, so if a table is larger than the /tmp partition, you can't repair it with the following steps.
If your /tmp partition is smaller than your largest database, you will have to specify a different tmp location. Here's an example:
myisamchk -r -q database/table.MYI --tmpdir=/home/tmp
Analysis and repair
Now we need to analyze the tables to see where the corruption is. The tables are located within /var/lib/mysql/. Every subfolder represents a database. The general idea is to run `myisamchk -s ./[database]/[table]. The -s flag means silent. Without it, you will receive a lot of status information that is irrelevant to the problem at hand. Usually there are a few more than a couple databases, so doing this manually can be a pain. Run a 'for' loop:
cd /var/lib/mysql
for x in `find * | grep .MYI`; do myisamchk -s $x; done
This should print out error reports on all of the corrupt tables. For every corrupt table, run the following command:
myisamchk -r -q [table]
Once the repair has completed, you want to make sure it actually accomplished what you sent it in to do. Run another check:
for x in `find * | grep .MYI | grep -v ".bak" | grep -v ".back"`; do myisamchk -s $x; done
If that reports any problems, it means the previous repair didn't fix everything. That's not a huge deal, because we just used the most simplistic and least invasive repair method. The other methods have a fair chance of causing damage, so you'll want to back things up from here.
Make a copy of any tables you are about to repair:
cp [database]/brokentable.MYI{,.bak}
Now try running a beefier repair against the table. Don't use the -q flag.
myisamchk -r [database]/brokentable.MYI
Once you've tried to repair the tables again, run another check. If it still reports errors, try using -o instead of -r. The -o flag uses an older repair strategy that tries a few more things than the newer, but is slower.
myisamchk -o [database]/brokentable.MYI
Run one more check to be sure you've caught everything.
Wrap-up
When you are done repairing the tables, don't forget to start MySQL again:
/etc/init.d/mysql start
And, if you're running cPanel:
/etc/init.d/chkservd start
Corrupted tables can cause a high load, or cause MySQL to crash fairly often. If you do have a problem with corrupted tables, you should see entries in the MySQL error log indicating this. The error log is usually located at /var/lib/mysql/HOSTNAME.err.
In that filename, "HOSTNAME" indicates the base hostname of your server. You can determine your server's hostname with the following command:
hostname
The most common error message in this log file that indicates you should attempt a repair on the MySQL tables is (errno: 145), but you should also attempt a repair if you see many of the following error codes: 126, 127, 132, 134, 135, 136, 141, 144
The easy way to repair
You may have a tool on your server called "mysqlcheck". If so, you can attempt an automatic repair with the following command:
mysqlcheck -A --auto-repair
The mysqlcheck tool should be run while MySQL is running. Do not stop MySQL before attempting a repair using this method.
The advanced method
WARNING: The information below is intended for users with advanced knowledge of operating systems, control panels, and other aspects of server management. Do NOT simply copy and paste commands to resolve issues as you may severely harm your server, cause downtime, or incur billable support not covered under your DEFCON plan. Please open a support ticket if you feel uncomfortable with the suggestions provided.
Read me first
Myisamchk uses /tmp while repairing, so if a table is larger than the /tmp partition, you can't repair that one with the following steps.
If you /tmp is smaller, you can repair it utilizing a temp tmp folder... something like the following:
myisamchk -r -q database/table.MYI --tmpdir=/home/tmp
Prep work
Before you start modifying tables, you should stop MySQL or you'll get a lot of false positives on the check, and a lot of problems on the repair. So before you go any further, stop MySQL. Even before that, if you have cPanel, you should first stop chkservd:
/etc/init.d/chkservd stop
Chkservd is cPanel's service monitor. It checks every eight (8) minutes to ensure all services are running, and if it detects any problems it will attempt to restart the service.
After chkservd is stopped, or if you do not have cPanel installed, stop MySQL:
/etc/init.d/mysql stop
Potential problem with myisamchk
Myisamchk uses /tmp while repairing, so if a table is larger than the /tmp partition, you can't repair it with the following steps.
If your /tmp partition is smaller than your largest database, you will have to specify a different tmp location. Here's an example:
myisamchk -r -q database/table.MYI --tmpdir=/home/tmp
Analysis and repair
Now we need to analyze the tables to see where the corruption is. The tables are located within /var/lib/mysql/. Every subfolder represents a database. The general idea is to run `myisamchk -s ./[database]/[table]. The -s flag means silent. Without it, you will receive a lot of status information that is irrelevant to the problem at hand. Usually there are a few more than a couple databases, so doing this manually can be a pain. Run a 'for' loop:
cd /var/lib/mysql
for x in `find * | grep .MYI`; do myisamchk -s $x; done
This should print out error reports on all of the corrupt tables. For every corrupt table, run the following command:
myisamchk -r -q [table]
Once the repair has completed, you want to make sure it actually accomplished what you sent it in to do. Run another check:
for x in `find * | grep .MYI | grep -v ".bak" | grep -v ".back"`; do myisamchk -s $x; done
If that reports any problems, it means the previous repair didn't fix everything. That's not a huge deal, because we just used the most simplistic and least invasive repair method. The other methods have a fair chance of causing damage, so you'll want to back things up from here.
Make a copy of any tables you are about to repair:
cp [database]/brokentable.MYI{,.bak}
Now try running a beefier repair against the table. Don't use the -q flag.
myisamchk -r [database]/brokentable.MYI
Once you've tried to repair the tables again, run another check. If it still reports errors, try using -o instead of -r. The -o flag uses an older repair strategy that tries a few more things than the newer, but is slower.
myisamchk -o [database]/brokentable.MYI
Run one more check to be sure you've caught everything.
Wrap-up
When you are done repairing the tables, don't forget to start MySQL again:
/etc/init.d/mysql start
And, if you're running cPanel:
/etc/init.d/chkservd start
Quota Problem
When quotas show as 0 for all the users and /scripts/fixquotas doesn\'t fix the problem, then most likely /home/aquota.users is missing. To fix the problem run the commands: touch /home/aquota.user chmod 744 /home/aquota.user Then, run /scripts/fixquotas again and everything should be fine.
Subscribe to:
Posts (Atom)
