Tuesday, May 12, 2009

Monday, May 4, 2009

To test packet lost

#mtr -r -c 10 myhost.mydomain.com
HOST: xxxxx.xxx.xxx Loss% Snt Last Avg Best Wrst StDev
1. xxxxxxxx 0.0% 10 0.2 0.2 0.2 0.3 0.0
2. xxxxxxxx 0.0% 10 0.6 1.4 0.5 9.2 2.8
3. xxxxxxxx 0.0% 10 2.6 1.2 0.6 3.1 1.0

Sunday, April 5, 2009

Generating a syslog message

#logger -i -t yourname "This is a test"

=> Message should appear at /var/log/messages.

Thursday, April 2, 2009

MySQL: show disk space occupied by database

#mysql -uroot -p -D -e "show table status\G"| egrep "(Index|Data)_length" | awk 'BEGIN { rsum = 0 } { rsum += $2 } END { print rsum/1024/1024 "M"}'

Tuesday, February 3, 2009

rpmdb: Lock table is out of available locker entries

rpmdb: Lock table is out of available locker entries

If up2date throws some horrible Python errors and rpm says “rpmdb: Lock table is out of available locker entries”, you can restore your system to normality with the following:

The errors:
rpmdb: Lock table is out of available locker entries
error: db4 error(22) from db->close: Invalid argument
error: cannot open Packages index using db3 - Cannot allocate memory (12)
error: cannot open Packages database in /var/lib/rpm

Make a backup of /var/lib/rpm in case you break something:
tar cvzf rpmdb-backup.tar.gz /var/lib/rpm

Remove the Berkeley databases that rpm uses:
rm /var/lib/rpm/__db.00*

Make rpm rebuild the databases from scratch (may take a short while):
rpm --rebuilddb

Now, check rpm to make sure everything is okay:
rpm -qa | sort

Why does this happen?
When rpm accesses the Berkeley database files, it makes temporary locker entries within the tables while it searches for data. If you control-c your rpm processes often, this issue will occur much sooner because the locks are never cleared.

Saturday, January 24, 2009