2

I have set up an init-script to control the state of a VirtualBox VM:

#!/bin/sh
#chkconfig: 35 99 5
#description: vTiger virtual machine

### BEGIN INIT INFO
# Provides: vtigervm
# Required-Start: $local_fs
# Requider-Stop: $stop_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Short-Description: Manage vTiger virtual machine
# Description: Utility to start and stop vTiger virtual machine on VirtualBox
### END INIT INFO

start()
{
    echo -n "Starting vTiger"
    echo
    su myuser -c '/usr/bin/VBoxManage startvm "vTiger" --type headless'
    echo "Started virtual machine" >> /var/log/messages
}

stop()
{
    echo -n "Shutting vTiger down..."
    echo
    su myuser-c '/usr/bin/VBoxManage controlvm "vTiger" acpipowerbutton'
    while [ ! -z "`su - juhani -c '/usr/bin/VBoxManage list runningvms | grep vTiger'`" ]; do
        echo -n "."
        sleep 1
    done
    echo "Done."
    echo "Stopped virtual machine" >> /var/log/messages
}

status()
{
    echo -n "Running VMs: "
    su myuser -c '/usr/bin/VBoxManage list runningvms'
    echo
    if [ -z "`su - juhani -c '/usr/bin/VBoxManage list runningvms | grep vTiger'`" ]; then
        RETVAL=3    
    else
        RETVAL=0
    fi
    echo "Queried virtual machine status" >> /var/log/messages
}

echo "Called virtual machine management script with: $1" >> /var/log/messages
case "$1" in
  start)
        start
   ;;

  stop)
        stop
   ;;

  restart|try-restart|condrestart|reload)
        stop
        start
   ;;

  status)
        status
   ;;

  *)
        echo $"Usage: $0 {start|stop|restart|status}"
        exit 1
   ;;
esac

exit $RETVAL

The system is CentOS 6.5. If I manually run service [start|stop|status] vtigervm, it works as I expect it to. If the VM is running, $? after the service vtigervm status returns 0, and 3 if it is stopped. I installed it with chkconfig and it created among a few others rc5.d/S99vtigervm and rc0.d/K05vtigervm.

The problem

When I start the system it starts the "service", but on shutdown it does not even run the scripts.

grep "virtual machine" /var/log/messages shows:

*[machine starting]*
Called virtual machine management script with: start
Started virtual machine
*[shutdown -h now]*
*[machine stopped]*

What I expect:

*[machine starting]*
Called virtual machine management script with: start
Started virtual machine 
*[shutdown -h now]*
Called virtual machine management script with: status
Queried virtual machine status
Called virtual machine management script with: stop
Stopped virtual machine
*[machine stopped]*

File permissions & etc:

# ls -lah /etc/rc0.d/
lrwxrwxrwx. 1 root root 13 7.2. 17:49 /etc/rc0.d/K05atd -> ../initd.d/atd
lrwxrwxrwx. 1 root root 18 9.2. 00:06 /etc/rc0.d/K05vtigervm -> ../initd.d/vtigervm
slm
  • 363,520
  • 117
  • 767
  • 871
varesa
  • 2,336
  • 5
  • 20
  • 19
  • I found this dup which didn't have a workable A. I've flagged the other as a dup to this one, since it has actual solutions to the problem. http://unix.stackexchange.com/questions/71941/calling-a-script-on-machine-shutdown – slm Feb 09 '14 at 01:41
  • @slm I only found one on stackoverflow, which didn't really have an aswer (for me atleast) – varesa Feb 09 '14 at 01:47
  • Yeah surprisingly there wasn't a lot of ppl having this particular issue which I find suspicious. – slm Feb 09 '14 at 01:49

2 Answers2

4

Idea #1

Try putting a -x at the top of the service script, this will put the shell into debug mode so that you'll get any output that's being generated by the script.

#!/bin/sh -x

Idea #2

Also you might want to add the process name to the top of the chkconfig comment macros as well.

# processname: vtigervm

You may need to change this value to whatever's appropriate for you situation.

Idea #3

As suggested in @RickBeam's answer and confirmed by this link I found on the CentOS forums, titled: "chkconfig/init.d not calling shutdown with solution", you'll need to manage the creation and destruction of a file in /var/lock/subsys. You can add these lines to your start() and stop() functions to do it:

start()
{
...
touch /var/lock/subsys/vtigervm
}

stop() {
...
rm -f /var/lock/subsys/vtigervm
}
slm
  • 363,520
  • 117
  • 767
  • 871
  • Even if it never starts a process called like that? – varesa Feb 09 '14 at 00:47
  • Sorry change the name to whatever it actually is. – slm Feb 09 '14 at 00:52
  • Also, where does `-x` send the output to, if the script is run by `init`? `dmesg`/`/var/log/messages`? – varesa Feb 09 '14 at 00:59
  • Yes it should go to /var/log/messages. – slm Feb 09 '14 at 01:02
  • Your answer isn't an answer. When(if) deleted, the DV will go with it. – Ricky Feb 09 '14 at 01:24
  • @RickyBeam Your answer might well be correct, but so may this one be. I was wondering which one to give the points. I think they will go to slm because you'r just a bit too disrespectful, sorry. (I know this answer in one of its states was not a real "answer") – varesa Feb 09 '14 at 01:45
  • @varesa - see here: http://unix.stackexchange.com/questions/28611/how-to-automatically-start-and-shut-down-virtualbox-machines – slm Feb 09 '14 at 01:55
  • @slm Most of those (I'm now on my phone so limited screen estate) seem like scripts that are alike to the one template I based my service on. Looking at the first answer, it would seem that there is an easy way to handle shutdowns. When I searched, I found so many conflicting, hard and badly documented ways it is "supposed to be handled", that I decided a simple service like that would be easiest/safest. I hadn't looked at Vagrant before – varesa Feb 09 '14 at 02:34
  • @varesa - OK. Yeah I just wanted to make you aware, there might be alternatives there or not, but at least you can decide for yourself. – slm Feb 09 '14 at 02:35
2

Your script has to touch /var/lock/subsys/... to indicate it's running. Look at the atd or crond init scripts as an example, and /etc/rc for how it's actually parsed.

(Note: I'm looking at /etc/rc for Fedora)

# First, run the KILL scripts.
for i in /etc/rc$runlevel.d/K* ; do

    # Check if the subsystem is already up.
    subsys=${i#/etc/rc$runlevel.d/K??}
    [ -f /var/lock/subsys/$subsys -o -f /var/lock/subsys/$subsys.init ] \
            || continue
    check_runlevel "$i" || continue

    # Bring the subsystem down.
    [ -n "$UPSTART" ] && initctl emit --quiet stopping JOB=$subsys
    $i stop
    [ -n "$UPSTART" ] && initctl emit --quiet stopped JOB=$subsys
done
slm
  • 363,520
  • 117
  • 767
  • 871
Ricky
  • 1,327
  • 8
  • 8
  • Ok, I thought `status` returning valid codes was enough. – varesa Feb 09 '14 at 00:47
  • FC2, but CentOS does exactly the same thing. (exact same file, in fact) – Ricky Feb 09 '14 at 00:55
  • @slm Maybe it's because of some hard-to-update software? I know a few companies that still have a bunch of old DOS pcs and some Netware stuff in-house – varesa Feb 09 '14 at 01:03
  • 1
    It's obviously not an *original* FC2 (nor is the RH9 machine). Or, the, ahem, RH 4.1 machine. (holy cow, it's running a 14 year old kernel!!!, dual PII-333) There's a RH6.2(?) around here somewhere -- i.e. the last sparc release. – Ricky Feb 09 '14 at 01:06
  • @varesa, it's more a factor of "you don't *upgrade* FC, you *reinstall*" which is why I've used debian for many years now. – Ricky Feb 09 '14 at 01:07
  • @RickyBeam Well it's been a few years since I used F*C*, but I have update some of the F series just fine :) I remember them being a PITA in the past though – varesa Feb 09 '14 at 01:10
  • @slm I touched the file, but I do not think it worked. Then I also specified the processfile, which made it work. It could very well be both :) – varesa Feb 09 '14 at 01:22
  • @slm The post you linked to also shows `processname` being specified – varesa Feb 09 '14 at 01:26
  • @slm This is in change my first "advanced" init-script :) (Even that I have about 10 years on redhat-fedora core-fedora-centos-rhel) In the past I've not neeeded things like running the script on shutdown. – varesa Feb 09 '14 at 01:41
  • @slm Also this was just a bit more difficult because the script does not wrap around a process, but a wrapper which in turn starts a server, so I had to do some looking up at the processes & etc – varesa Feb 09 '14 at 01:51
  • @varesa - yeah I was wondering if that had something to do with it too. You're doing something fairly complex in your start/stop, usually they are just starting a executable that often times is the same name of the service. I thought Vagrant or VirtualBox provided a feature for doing this too? – slm Feb 09 '14 at 01:52