Debian – Updating start-stop-daemon on Debian

You can install Tomcat 6 to run under jsvc as user tomcat (not as root). Here's what I did last time I set it up:

I installed the Tomcat application under /usr/java/tomcat (CATALINA_HOME) and an instance under /var/lib/tomcat (CATALINA_BASE):

cd /usr/java
sudo tar xzvf ~/downloads/apache-tomcat-6.0.18.tar.gz
sudo ln -s apache-tomcat-6.0.18 tomcat
sudo /usr/sbin/useradd -d /var/lib/tomcat -c "Apache Tomcat" -m -s /sbin/nologin tomcat
cd /var/lib/tomcat
sudo mkdir logs work temp
sudo chown tomcat:tomcat logs temp work
(cd /usr/java/tomcat && sudo tar cvf - conf webapps) | sudo tar xvf -
sudo chmod -R g+rw webapps conf
sudo chown -R tomcat:tomcat webapps conf
cd webapps/
sudo rm -rf docs examples manager host-manager
cd ../conf
sudo chmod g+r *

Then I built the jsvc wrapper:

cd
tar xzvf downloads/apache-tomcat-6.0.18.tar.gz
tar xzvf apache-tomcat-6.0.18/bin/jsvc.tar.gz
cd jsvc-src
chmod +x configure
./configure --with-java=$JAVA_HOME
make
./jsvc --help
sudo cp jsvc /usr/local/sbin/ 

Finally, I tightened the permissions on the instance directories:

cd /var/lib/tomcat
sudo chmod -R 0700 conf
sudo chmod -R 0750 logs
sudo chmod -R 0700 temp
sudo chmod -R 0700 work
sudo chmod -R 0770 webapps/
sudo chown -R tomcat:tomcat conf
sudo chown -R tomcat:tomcat logs

When you run Tomcat now, you'll need to start it using jsvc, so add this script as /etc/init.d/tomcat and symlink it appropriately:

#!/bin/sh
#
# tomcat       Startup script for the Apache Tomcat Server running under jsvc
#
# chkconfig: 345 85 15
# description: Apache Tomcat
# pidfile: /var/run/jsvc.pid

JAVA_HOME=/usr/java/jdk1.6.0_13
CATALINA_HOME=/usr/java/apache-tomcat-6.0.18
CATALINA_BASE=/var/lib/tomcat
JAVA_OPTS="-Djava.awt.headless=true"
JMX_OPTS="-Dcom.sun.management.jmxremote.port=1099 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false"

DAEMON_APP=/usr/local/sbin/jsvc
TOMCAT_USER=tomcat

# Everything below should be okay
PID_FILE=/var/run/jsvc.pid
LOCK_FILE=/var/lock/tomcat

PATH=/sbin:/bin:/usr/bin
. /lib/init/vars.sh

. /lib/lsb/init-functions

[ -x $JAVA_HOME/bin/java ] || exit 0
[ -x $DAEMON_APP ] || exit 0
[ -d $CATALINA_HOME/bin ] || exit 0
[ -d $CATALINA_BASE ] || exit 0

RETVAL=0
prog="jsvc"

CLASSPATH=\
$JAVA_HOME/lib/tools.jar:\
$CATALINA_HOME/bin/commons-daemon.jar:\
$CATALINA_HOME/bin/bootstrap.jar

start() {
  # Start Tomcat
  log_daemon_msg "Starting Apache Tomcat"
  $DAEMON_APP \
    -user $TOMCAT_USER \
    -home $JAVA_HOME \
    -wait 10 \
    -pidfile $PID_FILE \
    -outfile $CATALINA_BASE/logs/catalina.out \
    -errfile $CATALINA_BASE/logs/catalina.out \
    $JAVA_OPTS $JMX_OPTS \
    -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \
    -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \
    -Dcatalina.home=$CATALINA_HOME \
    -Dcatalina.base=$CATALINA_BASE \
    -Djava.io.tmpdir=$CATALINA_BASE/temp \
    -cp $CLASSPATH \
    org.apache.catalina.startup.Bootstrap start 2>/dev/null 1>&2
  RETVAL=$?
  if [ 0 -eq $RETVAL ]; then
    touch $LOCK_FILE
    log_end_msg 0
  else
    log_end_msg 1
  fi
}

stop() {
  # Stop tomcat
  log_daemon_msg "Stopping Apache Tomcat"
  $DAEMON_APP \
    -stop \
    -pidfile $PID_FILE \
    org.apache.catalina.startup.Bootstrap 2>/dev/null 1>&2
  RETVAL=$?
  if [ 0 -eq $RETVAL ]; then
    rm -rf $LOCK_FILE
    log_end_msg 0
  else
    log_end_msg 1
  fi
}

restart() {
  stop
  sleep 5
  start
}

# See how we were called.
case "$1" in
  start)
    start
    ;;
  stop)
    stop
    ;;
  restart)
    restart
    ;;
  status)
    status $prog
    ;;
  condrestart)
    [ -f $LOCK_FILE ] && restart || :
    ;;
  *)
    log_action_msg "Usage: $0 {start|stop|restart|status|condrestart}"
    exit 1
esac

exit $?

It seems you started off with the recommended procedure for upgrading which is great. I recommend trying to stick to that instead of prematurely doing a dist-upgrade. This procedure is worked out by testing on thousands of systems and is what we think is your best chance of a smooth upgrade.

In this case when you are doing apt-get upgrade we are EXPECTING lots of packages to be held back. That is by design. We want to do just a minimal upgrade in order to get the new kernel and udev installed, then reboot, then do the rest of the upgrade with dist-upgrade.

You should be concentrating on this error:

linux-image-2.6-amd64: Depends: linux-image-2.6.32-5-amd64 but it is not going to be installed

There is some reason why apt doesn't want to install linux-image-2.6.32-5-amd64. Find out by trying to install it directly with apt-get install linux-image-2.6.32-5-amd64, That will either install it, or will tell you specifically what is wrong with this package. When this results in a problem with another package, do the same with this package, by trying to install it directly, until you reach a root cause. Once the kernel is successfully installed, proceed with the upgrade instructions from there.

One artifact that doing this will have which may be undesired is marking the linux-image-2.6.32-5-amd64 package as automatically installed. After the upgrade is complete, and you are happy with the results, you might run apt-mark auto linux-image-2.6.32-5-amd64 to mark this package as automatically installed.

The reason that /etc/debian_version reads 6.0.5 is that you already update the base_files package. This is not a surpise.

The problems with mixing aptitude and apt-get were resolved with apt-get version 7.0 a few years ago, you should feel free to mix their use at will. In fact, Debian recommended aptitude for upgrading from one major release to another in the past and now recommends apt-get, so clearly Debian is recommending using both. We will recommend whichever one seems to work better for a given upgrade. On the lenny->squeeze upgrade, aptitude tends to think "too hard" about finding an optimal upgrade path, and the more simple dependency resolution in apt-get works for more people.