[269] Initial fix for msm not shutting down when server is shutdown/reboot

[milesvp]

This fix is for issue 269. After fighting this one for 4 hours last night, I finally learned that init.d relies on lockfiles for initiating shutdown of a service. Google returns many results like this:

http://www.nico.schottelius.org/blog/why-centos-does-not-stop-your-init-script/

So I went ahead and added lock creation and removal of /var/lock/subsys/msm in the obvious places in /etc/init.d/msm

Now on reboot and shutdown, msm properly is stopped, and RAM is copied to disk.

I tested this on Amazon Linux (centos based), works for both reboot and shutdown. Also works when stopping the AWS instance from the AWS dashboard.

[renderorange]

Hi milesvp, I'm going to be doing some testing for your pull request, then should be free to merge and bump versions tonight. I'll let you know if I find any issues or have any questions.

[renderorange]

I did a little testing on centos 6 and have one initial concern.

Adding the lock file creation and deletion to the start and stop all functions will trigger only when msm is run via the following:

/etc/init.d/msm start
/etc/init.d/msm stop

My only concern is when starting or stopping individual servers, the lock file isn't created or destroyed.

For example, the following:

/etc/init.d/msm server stable start
/etc/init.d/msm server stable stop

these won't touch or remove the lock file.

I haven't tested on cent 7 or ubuntu at all; overall, it should be tested in more platforms.

I just wanted to hear your thoughts on the previous.

Thanks.

[milesvp]

Thanks for the response! I was hoping there was still some regular maintenance on this project :)

The intent of the patch was really only for the registering and de-registering of init.d on startup and shutdown/reboot. I needed it for some of the work I'm doing around running minecraft servers hourly at AWS, and automated spinning up and shutting down of servers using EBS. I haven't done a lot of work with init.d startup scripts, so I was surprised to find a requirement for lock files. I'm also just learning about msm, so I might not know some of the more common use cases, so I apologize if I've missed some glaring omission with this patch.

I've spent about 15 minutes now in the code, and I'm having a hard time finding any reference to stable. Also, Grepping the code base returns nothing.

miles /checkouts $ git clone [email protected]:msmhq/msm.git msm.original
Cloning into 'msm.original'...
remote: Counting objects: 2829, done.
remote: Total 2829 (delta 0), reused 0 (delta 0), pack-reused 2829
Receiving objects: 100% (2829/2829), 1.64 MiB | 83.00 KiB/s, done.
Resolving deltas: 100% (1299/1299), done.
Checking connectivity... done.
miles /checkouts $ grep -ir stable msm.original
miles /checkouts $

Also, I've tried running /etc/init.d/msm server stable stop, and /etc/init.d/msm stable stop. Neither have worked.

[ec2-user@ip-172-30-0-200 ~]$ sudo su - minecraft
Last login: Sun Nov 22 09:14:49 UTC 2015 on console
-bash-4.2$ msm version
Minecraft Server Manager 0.9.4 Beta
-bash-4.2$ msm foo status
Server "foo" is running.
-bash-4.2$ msm foo stable stop
No such command. See /usr/local/bin/msm help
-bash-4.2$ msm server
No such command. See /usr/local/bin/msm help
-bash-4.2$ msm server help
No such command. See /usr/local/bin/msm help
-bash-4.2$ msm server stable stop
No such command. See /usr/local/bin/msm help
-bash-4.2$ /etc/init.d/msm server stable stop
No such command. See /etc/init.d/msm help

[ec2-user@ip-172-30-0-200 ~]$ sudo /etc/init.d/msm
No such command. See /etc/init.d/msm help
[ec2-user@ip-172-30-0-200 ~]$ sudo /etc/init.d/msm server stable stop
No such command. See /etc/init.d/msm help
[ec2-user@ip-172-30-0-200 ~]$ sudo /etc/init.d/msm foo stable stop
No such command. See /etc/init.d/msm help

Can you tell me what I'm missing? Is this an OS thing that I'm ignorant of?

[milesvp]

Red Hat Enterprise Linux 7.1 (HVM), SSD Volume Type - ami-4dbf9e7d

sudo yum install wget
wget -q http://git.io/lu0ULA -O /tmp/msm && bash /tmp/msm

Hmm, ok, so once I get everything working so that I can force to ram, once again, nothing saves on system reboot.

Sadly, RHEL7.1 uses systemd. And so the lockfile isn't enough to get it to run msm stop prior to reboot either. I see that the repo has an msm.service file. But locate msm.service doesn't find the file. chkconfig --list shows msm registered. RHEL 7 still supports systemV, https://access.redhat.com/articles/754933, but I'm not sure they are properly shutting down systemV services (for instance, /etc/rc.d/rc script that handles runlevel changes doesn't exist in RHEL7).

I'm gonna need more digging.

[renderorange]

My apologies, I should have clarified, and I typed it wrong. That command was simple an example of starting and stopping a single server.

# msm stable [start|stop]

In my case, I have a server named stable.

As for the systemd registration, usage is discussed here - #145 - but only briefly.

The note in the previous issue talks about a slight change in installation and system usage, which I generally agree with. If msm were installed to a different location, say, /usr/local/bin, for all systems, the individual installers could be retooled for Cent6 and 7 (non-systemd vs systemd usage), as well as Ubuntu.

msm is largely agnostic, which is a good thing, but the individual system control could use some work. If msm weren't assumed to be an init script, and more like a piece of software, then the different control systems could control it differently.

That change would definitely require a new parent version, as it would change in non-backward compatible ways.

[milesvp]

Thanks for the clarification. I was starting to be afraid you were using some future build that I didn't have access to.

My understanding is the lock file is only supposed to be created on (successful) startup of init.d scripts. And the lock file is only supposed to be removed on (successful) shutdown of init.d scripts. For init.d, scripts are registered based on runlevels, and changing the runlevel may trigger a start or stop of the script.

Line 18-19 of /etc/init.d/msm:

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

This shows that changing to runlevel 2-5 trigger a start, and 0,1,6 trigger a stop.

The lock file is checked on runlevel change. If the lock is there, it won't run /etc/init.d/msm start, this prevents work that may destroy/duplicate state, like a forking process that would create multiple daemons. Similarly, if the lock isn't there, it won't run /etc/init.d/msm stop, again to prevent destroying state, like rotating an already rotated log file.

So I wouldn't want /etc/init.d/msm start/stop to touch/delete the lock file, but I would expect /etc/init.d/msm start/stop to touch/delete the lock file.

The final piece of the puzzle, is that shutdown/reboot trigger a system change to runlevel 0, which means that /etc/init.d/msm stop should be called. Currently it is not, and this lock file was the simplest fix I could come up with that would allow a systemV distro to write RAM to disk on shutdown.

Also, the lock file doesn't stop someone from manually running /etc/init.d/msm start/stop, so the only impact I expect the script to have is to allow shutdown to run /etc/init.d/msm stop.

At this point, about the only concern I have, is that some distros might have the lock file somewhere else, and that /var/lock/subsys doesn't exist. Maybe the touch line should be something like

touch /var/lock/subsys/msm || true