Xubuntu

I've been running Ubuntu 10.04 for a couple of years, but it goes end-of-life soon. I knew that upgrading would more-or-less mean learning a new window manager: Unity or something else. I decided to try going with XFCE in Xubuntu 12.04 (which will have support until April 2017).

I have so far been pretty happy with it. I backed up everything I could think of to a second hard drive, and then did a fresh install off of a USB drive. It didn't take long, and then I spent a couple of hours restoring files and setting up software and stuff, such as...

• installing google chrome and importing bookmarks (I'd exported them prior to the upgrade)
• restoring ~/.purple so that pidgin would work
• installing postfix and configuring it to relay off of gmail, so that logwatch and my cron jobs would land in my gmail inbox (I'd already done this, so I just had to restore a couple of files)
• installing VirtualBox and restoring ~/.virtualbox (and my guest machines booted without much complaint)
• pointing gmusicbrowser at my MP3 collection and skinning it to look like rhythmbox (there are some minor differences I'm still getting used to, but it looks like the playlists I exported from rhythmbox import right into gmusicbrowser, so that's a pleasant surprise)
• setting up an encrypted subdirectory in $HOME

I find that I don't much care for the panel at the bottom (the one that's supposed to look like OS X), so I may end up removing it. And I'm finding that the keyboard shortcut for "maximize window" is flaky for some reason. But those are about the only two wrinkles I've found. It was otherwise pretty painless, and it took less time than I expected.

Red Hat and CentOS process locks do not belong in /var/lock/subsys

I have a bash script that runs via cron every night. It's a software package repository mirroring process, so it has the potential to run for a long time. I don't want two of them running at the same time, and I want to know if one is running for more than 24 hours.

So the first thing the script does is to check for the presence of a lock file in a particular location. If the lock file exists, that means that the previous instance didn't complete, so it spits out an error message (which will land in my email) and quits. If the script does not find the lock file (which is the normal condition), it creates the lock file (via touch) on the very next line. The very last thing the script does is to remove the lock file.

if [ -f /var/lock/subsys/mirror ] ; then
    echo 'previous instance running--quitting'
    exit
fi
touch /var/lock/subsys/mirror

# long-running mirroring process...

rm -f /var/lock/subsys/mirror

We have scheduled downtime from time to time to do operating system upgrades and other maintenance. I typically create the lock file manually at the beginning of maintenance, because I don't want my local repository changing while I'm running updates. And then I manually remove the lock file at the end of maintenance.

We did maintenance last night, and the server that runs this mirroring process was having some kind of problem. We ended up rebooting the server (which, in this case, resolved the problem we were experiencing).

Turns out that part of the reboot process on Red Hat (and CentOS) is to clear out the /var/lock/subsys directory, which is where I'd been putting the lock file for the mirroring process. Oops.

Fortunately, the reboot happened after the cron job, and so the cron job didn't run unexpectedly. But that was just a matter of lucky timing.

So today I'm moving the lock file to /var/run. And I may as well make it work like the other files in that directory. So instead of

touch /var/lock/subsys/mirror

I'll do

echo $$ > /var/run/mirror.pid