Ramdisk getting unmounted before it's unloaded

[dghodgson]

tom from forums.bukkit.org:

root@ip:/etc/init.d# ./minecraft stop
craftbukkit.jar is running... stopping.
craftbukkit.jar could not be shut down... still running.
Can't unload ramdisk, craftbukkit.jar is still running!
Ramdisk mounted at /home/dfomain1/minecraft/servers/dfo1/minecraft_ramdisk.... unmounting
Ramdisk unmounted

And then it rolls back ???

Reko from forums.bukkit.org:

get this when stopping server

Can't unload ramdisk, cb.jar is still running!
Ramdisk mounted at /root/minecraft/mcram.... unmounting
umount: /root/minecraft/mcram: device is busy.
(In some cases useful info about processes that use
the device is found by lsof(8) or fuser(1))
umount: /root/minecraft/mcram: device is busy.

It appears to be an issue with the some servers taking too long to shut down, and the script doesn't wait long enough so the mcrd_unload function gets called before the service has stopped and subsequently fails as a result.

The main problem is that while mcrd_unload fails safely and opts to not unload the world files as the service is still running, mcrd_unmount decides to chug right along anyway despite the fact that the ramdisk has not yet been unloaded.

[WillHaggerty]

So we need to make sure that the instance is shutdown (maybe even find a way to say whether the RD was copied) before the RD can be un-mounted. Is this about the gist of it?

[Paswaru]

Maybe something like this. Loop after sending the stop command and keep checking for the process to stop. This example will wait a max of 30 seconds.

Could even kill the process inside the if [ $counter .... in cases where the console isn't responding at all.

mc_stop() {
  if ps -U $USERNAME x | grep -v grep | grep -v -i SCREEN | grep $SERVICE > /dev/null
  then echo "$SERVICE is running... stopping."

    as_user "screen -p 0 -S $SCREEN_NAME -X eval 'stuff \"say $STOP_MSG\"\015'" ; sleep 5
    as_user "screen -p 0 -S $SCREEN_NAME -X eval 'stuff \"save-all\"\015'" ; sleep 10
    as_user "screen -p 0 -S $SCREEN_NAME -X eval 'stuff \"stop\"\015'" ; sleep 3

    counter=0
    while ps -U $USERNAME x | grep -v grep | grep -v -i SCREEN | grep $SERVICE > /dev/null; do
        if [ $counter -ge 30 ]; then
            echo "STOP FAILED!"
            break
        fi
        sleep 1
        let counter=counter+1
    done
  else echo "$SERVICE was not running."
  fi

  if ps -U $USERNAME x | grep -v grep | grep -v -i SCREEN | grep $SERVICE > /dev/null
     then echo "$SERVICE could not be shut down... still running."
     else echo "$SERVICE is shut down."
  fi
}

[dghodgson]

I'm not sure how best to handle the situation after the counter has run out though. We could either halt the stop process (for the script, the minecraft server would of course continue to halt), and let the user run the script a second time to properly unload and unmount the ramdisk. We could also display a prompt and ask the user to either tell the script to wait longer, or to kill the minecraft process. The other option though would be to do as Paswaru suggested and simply terminate the process after the timer.

The problem with the first option is that it will cause the data to be lost on shutdown (unless we write a function that gets called on shutdown which automatically unloads the ramdisk regardless of the circumstances).

The problem with the second option is that it could cause the system to hang on shutdown, which means it's not suited for an init script (maybe detect whether the stop command is getting called by a user versus the system and adjust accordingly?).

The problem with the third solution is that it could cause issues with some plugins, and potentially corrupt world data. Though I think it's probably the safest option as I've yet to have any issues killing bukkit with ctrl+c from the command line when testing configurations. Though Codecraft doesn't use many plugins, and the ones it does use are all well-written and widely used as far as I'm aware.

[dghodgson]

I think if it's possible to easily detect if the script is being called by the system, then it might not be a bad idea to blend the latter two options using an if-else statement somewhere.

[dghodgson]

I've pushed a preliminary fix for this issue to the development branch. It's pretty simple, really. Set a variable depending on how the mcrd_unload function exits, check for the contents of that variable in mcrd_unmount, and act accordingly.

It'll fix the issue for now, but it'll cause problems when restarting or shutting down the system.