Redmine/Webrick rc script

I've just installed redmine 1.3.2 on FreeBSD server and met several inconviniences.

1. It is not in ports


2. It depends on old versions of different ruby gems, which are already not in ports.
   In particular, it didn't want to work with rack 1.4.1 and I had to do
   

   
   # gem install rake -v=1.1.0
   

   
   


3. It doesn't have rc script to startup Webrick web server (I didn't want to install apache on this host)
   

So, I've taken mongrel_cluster rc script and made redmine rc script from it. It is here:

#!/bin/sh
# PROVIDE: redmine
# REQUIRE: DAEMON
# KEYWORD: shutdown
#
# This script is modified by placing the following variables inside
# /etc/rc.conf:
#
# redmine_enable (bool):
#       Set it to YES to enable this service.
#       Default: NO
# redmine_dir (path):
#       The directory containing redmine
#       Default: /usr/local/redmine/
# redmine_user (username):
#       The user to run redmine as
#       Default: redmine
# redmine_args (string):
#       Additional command flags for ruby
#       Default: "-e production -d"

. /etc/rc.subr

name=redmine
rcvar=redmine_enable

command="/usr/local/bin/ruby"

load_rc_config $name

: ${redmine_enable="NO"}
: ${redmine_dir="/usr/local/redmine/"}
: ${redmine_args="-e production -d"}
: ${redmine_user="redmine"}

start_cmd="redmine_cmd start"
stop_cmd="redmine_cmd stop"
restart_cmd="redmine_cmd restart"
status_cmd="redmine_cmd status"

redmine_cmd()
{

    if [ ! -d "${redmine_dir}/." ]; then
        warn "${redmine_dir} is not a directory."
        return 1
    fi
 
    case $1 in
        "start")
           su -l ${redmine_user} -c "cd ${redmine_dir} && pwd &&  eval  $command  script/server webrick $redmine_args"
        ;;
        "stop")
           if [ -f ${redmine_dir}/tmp/pids/server.pid ] ; then
             PID=$(/usr/bin/head -1 ${redmine_dir}/tmp/pids/server.pid)
             /bin/kill -s int $PID  2>/dev/null
             sleep 3 
             /bin/kill -s  0 $PID 2>/dev/null && /bin/kill -s kill $PID;
           fi
        ;;
        "restart")
           redmine_cmd stop
           redmine_cmd start
        ;;
        "status")
          if [ -f ${redmine_dir}/tmp/pids/server.pid ] ; then
                echo "PID file exists"
                PID=$(/usr/bin/head -1 ${redmine_dir}/tmp/pids/server.pid)
                /bin/kill -s  0 $PID 2>/dev/null && echo "Server is running with pid $PID" && exit 0;
                echo "But server is not running..." && exit 1;
           fi
           echo "Server is not running" && exit 0;
        ;;
    esac
}

run_rc_command "$1"

The interesting thing to note is that to terminate webrick correctly, you have to send it SIGINT, not SIGTERM.

Remember TRUNCATE peculiarities

Just remember the following about TRUNCATE:
1) It is DDL operation and so is not transactional in Oracle (issuing TRUNCATE will make an implicit commit)
2) It is not MVCC-safe in PostgreSQL.

What does it mean?

alp=> create table t199 as select * from pg_opclass ;
SELECT 117
alp=> BEGIN ;
BEGIN
alp=> TRUNCATE t199;
TRUNCATE TABLE
alp=> ROLLBACK ;
ROLLBACK                         ^
alp=> SELECT count(*) from t199;
 count 
-------
   117
(1 row)

So far, everything looks good: TRUNCATE was rolled back. Transactional DDL is a powerful PostgreSQL feature. But let's start parallel transaction. In first session I'll issue

alp=> \set PROMPT1 'T1> '

and in second:

alp=> \set PROMPT1 'T1> '

So, let's fun begin.

 
T1> BEGIN;
BEGIN
T1> SET transaction_isolation TO serializable;
SET
T1> UPDATE employees SET email=email;
UPDATE 103

T2> BEGIN ;
BEGIN
T2> TRUNCATE t199;
TRUNCATE TABLE
T2> COMMIT ;
COMMIT

T1> SELECT count(*) from t199;
 count 
-------
     0
(1 row)

Oops... What has happened? Let's repeat...

T2> INSERT INTO t199 SELECT * from pg_opclass;
INSERT 0 117

T1> BEGIN;
BEGIN
T1> SET transaction_isolation TO serializable;
SET
T1> UPDATE employees SET email=email;
UPDATE 103

T2> BEGIN ;
BEGIN
T2> DELETE FROM t199;
DELETE 117
T2> COMMIT ;
COMMIT

T1> SELECT count(*) from t199;
 count 
-------
   117
(1 row)

Do you see the difference? T2's DELETE didn't modified T1 snapshot... But TRUNCATE did. And what about "UPDATE employees"? It is just necessary to get real XID and snapshot for transaction.
So, the main idea: be attentive with "TRUNCATE". It is not just "fast DELETE", it has some not-so-evident consequences.