A blog about software development, primarily in Java and about web applications.

Friday, March 19, 2010

Cygwin 1.7 Upgrade

I'm a big fan of Cygwin and have used it for years. Without it, it's possible for me to be productive on Windows. The latest version of Cygwin is 1.7. This version changed a few things for.

The first was one they warned about, how Cygwin stores mount points. These are no longer stored in the Windows registry, but are instead read from /etc/fstab. Cygwin comes with a script who's purpose appears to be to create this file for you, but when I ran it nothing happened. So I was left creating my own /etc/fstab. Here's what mine looks like:

C:/cygwin/bin /bin ntfs binary,user 0 0
C:/cygwin/etc /etc ntfs binary,user 0 0
C:/cygwin/home /home ntfs binary,user 0 0
C:/cygwin/var /var ntfs binary,user 0 0
C: /c ntfs binary,user 0 0
C:/Documents\040and\040Settings/don/Application\040Data /n ntfs binary,user 0 0
C:/Documents\040and\040Settings/don/My\040Documents /m ntfs binary,user 0 0
W: /w ntfs binary,user 0 0
Y: /y webdrive binary,user 0

The second issue I ran into was that I didn't have /bin or /usr/bin in my PATH. The previous versions of bash/cygwin did this for me. I actually had a line in my .profile commented out that would have done this. I simply put it back in and was good to go.

So far these are the only issues I've had with the upgrade and they were relatively easy to fix.

Saturday, March 13, 2010

Calculating size of Oracle Database


select decode(least(sum(bytes), 1000000000),
1000000000, ROUND(sum(bytes)/1000000000) || 'GB',
ROUND(sum(bytes)/1000000) || 'MB') as database_size
from dba_segments;

The above query has the nice effect of displaying the size of the database in a human readable format.

DATABASE_SIZE
------------------------------------------
151GB

1 rows selected

Tuesday, March 2, 2010

Hudson v1.347 Kills Background Processes :(

I recently upgraded out Hudson instance after not touching it for quite a while. This quickly broke the set up we have in which Hudson stops and starts our Tomcat servers after a successful build to deploy the new code. The problem seems a change in the Hudson code that kills any background processes that a Hudson job leaves around. There's documentation about this issue at:

http://issues.hudson-ci.org/browse/HUDSON-2729
http://hudson.gotdns.com/wiki/display/HUDSON/Spawning+processes+from+build

We use the following shell script to stop and start Tomcat servers. The key part of the script is the setting of the environmental variable BUILD_ID=dontKillMe which overrides the default environmental variable setting Hudson gave the variable and thus prevents it from killing the background processes.


#!/bin/bash
#.Name
# startTomcat.sh
#.What
# Starts a tomcat container. This script handles some nuances of Hudson
# in which it kills background processes that you want to have stay alive
# after a build job (e.g. Restart Tomcat) finishes.
#
#.See
# http://issues.hudson-ci.org/browse/HUDSON-2729
# http://hudson.gotdns.com/wiki/display/HUDSON/Spawning+processes+from+build

exec 2>&1;

BUILD_ID=dontKillMe; export BUILD_ID;

if [ $# -ne 1 ]
then
echo "Usage: $0 full_path_to_tomcat_directory"
exit 1
fi

if [ ! -d ${1} ]
then
echo "Not a directory: ${1}"
exit 2
fi

echo $0 starting $(date)
set -x

pwd

cd $1

if [ $? -ne 0 ]
then
echo "Directory not found or has wrong permissions: $1"
exit 3
fi

pwd

./tomcat.sh stop

sleep 5

./tomcat.sh start >> ${1}/logs/start.log 2>&1

echo $0 completed $(date)

exit 0