I ordered my Dell XPS M1530 with the “extended”, 9-cell battery in the hopes that I could run on battery power for at least three hours.  After using my laptop for a few days I realized that I had got my wish:  It ran for about 4 hours with the screen dimmed to ~75%, the ondemand CPU governor enabled, and running a 3D-accelerated (Compiz) desktop.  This was with Ubuntu 7.10 (Gutsy Gibbon) and KDE 3.

Recently (well, months ago =) after migrating to KDE 4.1 in Ubuntu 8.10 I’ve had to plug my laptop in after about 2 hours.  Even if I dimmed the screen significantly and shut down non-essential services it still wouldn’t last very long.  More importantly, as time progressed I knew the problem would just get worse so I decided to investigate.  This investigation turned up some surprising tweaks that save a lot of power…

(more…)

Cron is not a particularly intelligent utility.  It will run a command whenever it is set to run–regardless of whether or not the last invocation of said command completed.  So if you have a command that puts a high load on your system and it’s time for cron to execute that same command again you’re going to be in a heap of trouble.

The solution to this problem is as old as cron itself but for some reason it seems to have gone missing in the minds of the general cron-using public.  Here it is:

* * * * * [ -n "`ps -ef | grep -v grep | grep myprocess`" ] && <execute myprocess>

That will only execute “myprocess” if it isn’t already running.  Here’s another way:

* * * * * [ ! -f /tmp/myprocess ] && touch /tmp/myprocess && <execute myprocess> && rm -f /tmp/myprocess.pid

Of course, it would be even better if ‘myprocess’ actually wrote a PID file itself so you wouldn’t have to manage it from within cron.  If ‘myprocess’ is a shell script here’s how you do that:

#!/bin/bash
[ ! -f /tmp/myprocess.pid ] && echo $$ > /tmp/myprocess.pid
<your code goes here>
rm -f /tmp/myprocess.pid

Of course, if your script is going that far you might as well go all the way:

#!/bin/bash
if [ -f /tmp/myprocess.pid ]; then
    echo "Not running since /tmp/myprocess.pid exists"
    exit 1
fi
echo $$ > /tmp/myprocess.pid
<your code goes here>
rm -f /tmp/myprocess.pid

It took me forever to figure this out because I could find ZERO examples after like 20 minutes of googling and at least 10 minutes of reading the docs (I’m sorry but, “see the MySQL documentation for more details” is *FAR* too ambiguous).  Anyway, so no one has to go through what I did here’s a real example of how to use SSL with the MySQLdb Python module:

#!/usr/bin/env python

ssl_settings = {'ca': '/etc/mysql/mysql_ca.pem',
    'cert': '/etc/mysql/mysql_cert.pem',
    'key': '/etc/mysql/mysql_key.pem'
}

db=MySQLdb.connect(host="mysqlserver",
    user="myuser",
    passwd="mypassword",
    db="mydatabase",
    ssl=ssl_settings
)

server_status = db.stat() # This was another thing that was non-obvious (to me anyway)
print server_status

# Perform a standard query
c = db.cursor()
c.execute("SELECT * from some_table")
row = c.fetchone()
print row

For reference, I was only able to get the SSL connection to work if I supplied at a minimum the ‘cert’ and ‘key’ parameters.  The ‘ca’ parameter isn’t necessary but it adds an extra layer of security (at trivial cost) so you might as well use it.

The really annoying thing about SSL in the MySQLdb module is that it doesn’t report whether or not it is actually using SSL (you could set ‘ssl=”blah”‘ and it would still continue on its merry way).  If you get the ssl settings parameter wrong it will still try to connect without using SSL–sending your queries in plaintext over the network.  To prevent this from happening I highly recommend you add the REQUIRE SSL parameter to the MySQL user you’re going to be using for connections…

mysql> GRANT ALL PRIVILEGES ON mydatabase.* to username@somehost
	      -> IDENTIFIED BY "secretpass" REQUIRE SSL;

Here’s a list of all the available keywords you can use in the ssl connection parameters (taken from here):