init scripts for boot AND shutdown

[droopysnowmen]

I've been working on an init script called stMC on my Ubuntu server, which I cannot get to work. I don't quite understand what it is that I'm doing wrong, because my script matched with the commands "start", "stop", "restart", and "status" all work.

I have also run

update-rc.d stMC defaults

before rebooting to put the symlinks in the right places.
In addition to that, I have tried

update-rc.d stMC start 2 3 4 5 . stop 0 1 6 .

with no success. The update command completes successfully, but upon reboot the script doesn't seem to have run correctly.

The script itself looks in the $1 argument for start, stop, etc. commands and does nothing if they are not specified. This seems to be in line with the other init scripts in the rcX.d directories. I didn't see any other way that they determined whether they should be starting or stopping.

Any help would be greatly appreciated.

[zombykillah]

Hi,
Do you tell the script what language you use
#!/bin/bash
?

Are any errors written in the log?

[droopysnowmen]

Yeah. I included #!/bin/bash in the script

As for the log, I checked dmesg but didn't see any evidence of the script.



EDIT:...Alright, so I just added an echo statement into the script to write out to a file in my home directory. When I reboot, this file shows up, but I only see one echoed line in it, so the script is running either on shutdown or startup, and not recieving "start" or "stop" arguments, or not checking for them right, or something.

[ptkobe]

I guess you are trying to do a classic "System V style init script" (init.d), not a upstart script (init).
So, you put your script at /etc/init.d/, made it executable and update-rc.d created the correct /etc/rc<runlevel>.d/[SK]NNname links, right?

Can you post your script? Do you have a ### BEGIN INIT INFO section?

EDIT: check your update-rc.d command. I think you forgot the NN sequence numbers:
$ sudo update-rc.d stMC start NN 2 3 4 5 . stop NN 0 1 6 .

Regards
Luis

[droopysnowmen]

Thanks for the responses and sorry for taking so long to get back here.
You are correct. I am trying a System V style init script, and I dropped my script in /etc/init.d/, made it executable, and ran update-rc.d. It put the correct files in the correct "rc" folders.
I did not forget the NN when I issued the actual command, I just missed them somehow when I was transcribing it into my post.
I have a ### BEGIN INIT INFO section, but it's quite possible that is the problem. I read the manpage which provided me little help on the subject, and I pieced it together from other init scripts in my init.d folder and from threads I found on the web.

Anyway, here is my script:

#!/bin/bash
#### BEGIN INIT INFO
# Provides:          Minecraft Server
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Minecraft Init Script
# Description:       Minecraft Init Script
### END INIT INFO


#Settings

SERVICE='Minecraft'
MCPATH='/home/master/minecraft'
JAR='minecraft_server.jar'
OPTIONS='nogui'
XMX='2000M'
XMS='512M'
CPU_COUNT='2'
COMMAND="java -Xmx$XMX -Xms$XMS -XX:ParallelGCThreads=$CPU_COUNT -jar $JAR $OPTIONS"
ME=`whoami`

#screen -d -m -S minecraft ./startMC.sh

mc_start() {
    if pgrep -u $ME -f $SERVICE > /dev/null
    then
	echo "$SERVICE is already running."
    else
        echo "Starting Minecraft $SERVICE Server..."
	pushd $MCPATH
	screen -dmS $SERVICE $COMMAND
	if pgrep -u $ME -f $SERVICE > /dev/null
	then
	    echo "$SERVICE is now running."
	else
	    echo "Error starting $SERVICE"
	fi
    fi
}
mc_save(){
    if pgrep -u $ME -f $SERVICE > /dev/null
    then
	echo "Saving world $SERVICE"
	#screen -x $SERVICE
	screen -p0 -S $SERVICE -X eval 'stuff "say Saving world. \015"'
	screen -p0 -S $SERVICE -X eval 'stuff "save-all\015"'
    else
	echo "$SERVICE is not running."
    fi
}
mc_stop(){
    if pgrep -u $ME -f $SERVICE > /dev/null
    then
	echo "Stopping Minecraft $SERVICE Server..."
	#screen -p0 -x $SERVICE
	screen -p0 -S $SERVICE -X eval 'stuff "say Server going down for maintenance.\015"'
	screen -p0 -S $SERVICE -X eval 'stuff "save-all\015"'
	sleep 10
	screen -p0 -S $SERVICE -X eval 'stuff "stop\015"'
	sleep 5
	if pgrep -u $ME -f $SERVICE > /dev/null
	then
	    echo "Failed to stop Minecraft $SERVICE Server."
	else
	    echo "Sucessfully stopped server."
	fi
    else
	echo "$SERVICE Server not running."
    fi
}
mc_status(){
    if pgrep -u $ME -f $SERVICE > /dev/null 
    then
        echo "Minecraft $SERVICE Server is running."
    else
        echo "Minecraft $SERVICE Server is not running."
    fi
}

echo ItRan >> /home/master/testInit
case "$1" in
    start)
        mc_start
        ;;
    restart)
	mc_stop
	mc_start
	;;
    status)
	mc_status
	;;
    save)
        mc_save
        ;;
    stop)
	mc_stop
	;;
esac
exit 0

EDIT: I just added a `runlevel` to the echo above my case statement. It appears it is running on shutdown, but not on startup.

EDIT 2: Alright, so I noticed that when running "update-rc.d stMC defaults" that the program warned me about "missing LSB information" so I set off trying to figure that out.

I moved the header above the #!/bin/bash, which didn't work, and after about a half hour of looking through the update-rc.d and insserv manpages, I realized I had an extra # in front of BEGIN INIT INFO. I removed it and now it doesn't warn me about the LSB information.

The script is still not running properly, however. Also, when run with defaults, update-rc.d puts the script very low in the run order (20). I have replaced $all with $local_fs $network $netdaemons for both start and stop since $all seemed to possibly be a gentoo only keyword, but still the script remained at 20.

[droopysnowmen]

Alright, I know this is a double-post, but I have managed to solve my problems and thought I'd share.

So I found out that my init script WAS running on startup. It occurred to me that my home directory is encrypted with ecryptfs and maybe wasn't mounted when my script was writing it's log, so I switched it to write to /var/log/testInit.log.
This showed that the script was running when expected (and I must have a testInit file in my home directory without my encrypted "drive" mounted). In addition, I placed an echo statement within the start function, and found that it too was running when expected.

So my problem was really one of my experience with the system and my knowledge of scripts and System V scripts.

My problem then was that my script's functions were not working correctly. I added echo statements to my script's start function and found that it reported it had successfully started. This is bizarre, because there is no reason it should've reported that.

My script worked fine when run from the console, but on startup it would claim success, but then leave no screen session to be found, and no trace in "ps aux."

Long story short(er) it was my encrypted home directory again. It wasn't mounted when the server started, so my .jar was nowhere to be found. I've moved it to a different directory and now my init script works beautifully!

I guess it's a lesson not to run server software from binaries in your home directory, (and possibly to avoid ecryptfs. that thing has caused me nothing but trouble.) The only thing I have left to do is clean up my script and figure out why it was reporting success when it failed.

[ptkobe]

Just a quick answer, no time
Should be something like:
# Provides: stMC

I'm thinking if you may put the ecryptfs init script on the # Required-Start: directive (LSBInitScripts - Debian Wiki). Something like:
# Required-Start: ecryptfs $local_fs $network
(replace ecryptfs with the correct init script file name)

You may have to use
# update-rc.d -f delete stMC
first and then
# update-rc.d stMC defaults
again (?) Don't know, I'm guessing

[droopysnowmen]

Just a quick answer, no time
Should be something like:
# Provides: stMC

I considered doing this, and may still change it should I find the need, but my main argument against it is that I may at some point want to start more than one of these servers. Since I have no dependencies on this service, it shouldn't cause problems, and since I haven't decided how to implement multiple servers yet, I'll leave it alone.

My guess is that I'd go the route of using stMC with additional arguments for starting different servers. Maybe have some config files that describe the names and locations of the different servers.

The other option I considered (and the reason for the different "# Provides:") is the route of an init script for each server. These servers can be processor intensive at times, so I would never run more than two or three. That makes it seem like it might be okay to have separate init scripts for the separate servers. This seems kind of sloppy to me, though.

I'm thinking if you may put the ecryptfs init script on the # Required-Start: directive
Something like:
# Required-Start: ecryptfs $local_fs $network
(replace ecryptfs with the correct init script file name)

See, I don't know if this would work still. I'm not sure that my encrypted home folder is mounted until I log in.

[ptkobe]

I just don't think you can use spaces on the Provides name. But right you are, all the way. I have totally miss the login/home directory issue.

Off topic, we may just add that the ~/.bashrc and ~/.profile (not ~/.bash_profile on ubuntu) files may be a solution for some, other, similar problems (setting env vars, running programs on login, ...). Difference between login shell and non-login shell | Admon Home

Regards
Luis

[droopysnowmen]

Sure. I use those scripts a lot on my local machine. They're great for almost everything you could want to run on login on a per user basis. On a server, however they're good for setting terminal color, maybe some environment variables, but not really much else. I really can't think of anything I'd want to start on a server when I log in and stop when I log off.