Rebooting kills systemd service

So I decided to start up the old minecraft server again for my friends a couple of days ago and this time I decided that this time I would actually setup it up a bit more proper this time. Now before I was using a screen session with the server just running in that, (I assume any sysadmins out there are dying a bit on the inside.) Anyways using some guides i found and many hours of debugging later I finally got the whole thing running being able to use “systemctl start” and “systemctl stop” without it just killing the server while it was live. Instead it now uses the remote console feature to stop it and let it save properly.

So this is where my question starts today, Why is it every time I reboot the system does it just kill the service instead of “stopping” it? From my understanding when your calling reboot its systemd itself that handles everything behind the scene which brings some more questions from myself. Now a little bit about the exact command i’m using. So using “reboot” straight it causes problems because of the pihole and the pihole user that is logged in. So then if when I use the “-i” flag to ignore everything it then kills it, which does make sense, but why would it kill everything instead of just the few things that are causing troubles. Lastly there is “sudo reboot” which seems to be the same as the previous option in this case.

I’m probably just missing something simple or I should be doing something else altogether.

And for a little more digging, if I “sudo pkill -u pihole” then “sudo reboot” it actually seems to work the way i would expect it to with the server giving a “server closed message” saying it got the command to close properly

PS: here is the systemd service file

Summary

[Unit]
Description=The Carpet Minecraft Server
Documentation=

Wants=network.target
After=network.target

[Service]
User=minecraft
Group=minecraft
KillMode=none
SuccessExitStatus=0 1

ProtectHome=true
ProtectSystem=full
PrivateDevices=true
NoNewPrivileges=true

PrivateTmp=true
InaccessibleDirectories=/root /sys /srv -/opt /media -/lost+found
ReadWriteDirectories=/var/minecraft/server
WorkingDirectory=/var/minecraft/server
ExecStart=/usr/bin/java -jar -Xms2G -Xmx8G fabric-server-launch.jar nogui
ExecStop=/var/minecraft/mcrcon/mcrcon -H localhost -P 25575 -p {REDACTED} stop

[Install]
WantedBy=multi-user.target

Does your “server closed message” appear in syslog? If so, are you sure it’s not just the syslog service stopping before your minecraft service stops?

How about systemctl reboot / what distro are you on? Is it the same as reboot?

To be honest never even heard of syslog, could you point me in the right direction? A quick google search suggests that its a remote logging… thing?

systemctl reboot looks the same as reboot
Im using Ubuntu 18.04 Server

On Ubuntu, your logging service is probably called:

rsyslog/syslog

If you look at its unit file:

/lib/systemd/system/rsyslog.service

2020-03-13-001

It runs rsyslogd without specifying a configuration file. So the default configuration file is used:

/etc/rsyslog.conf

2020-03-13-002

which default include all the entries in /etc/rsyslog.d

And you probably have an entry called default.conf:

/etc/rsyslog.d/50-default.conf

2020-03-13-003

That sends all non authentication system messages to /var/log/syslog.

I was suggesting that if you were looking in /var/log/syslog for confirmation that your minecraft service shutdown cleanly per your ExecStop entry in your minecraft unit file, that absence of that confirmation may be caused by the syslog service shutting down prior to the minecraft service shutting down, not by the minecraft process being “killed”.

From the manpage:

Note that it is usually not sufficient to specify a command for this setting that only asks the service to terminate (for example, by sending some form of termination signal to it), but does not wait for it to do so. Since the remaining processes of the services are killed according to KillMode= and KillSignal= or RestartKillSignal= as described above immediately after the command exited, this may not result in a clean stop. The specified command should hence be a synchronous operation, not an asynchronous one.

I haven’t run a Minecraft server in a long time, so I don’t remember anything. But make sure your stop command waits until the server exits or systemd will do the kill option.

Would there be some way I can specify a time for it to wait? The thing that gets me is that send the command for it to stop it will stops properly. From what I understand of the minecraft unit file is that it won’t let itself just close the program and instead it will sit and wait forever. This happens while the separate mcrcon is used to create a local remote connection to send the “stop” command and once it has saved and the program has closed itself it goes on its way.

If I had to take a guess, when I send a systemctl stop minecraft it has the time to wait and see how things play out and it works as intended, but when it encounters a reboot it doesn’t want to sit around and wait and gets impatient then finally kills it so the server can actually reboot.

I’m not using any logging systems on the sever itself, the client will tell you if the server was closed. However on a reboot I’m not getting the nice “server closed” message and instead java errors like it was killed. Also Thank you for helping me out.

ps. is there a better term than “killed” because I don’t know if i’m even calling it the right thing.

You might want to try using KillMode=mixed instead of KillMode=none.

With “none” it does not send TERM or KILL signals. It does not wait either. This is fine when running a stop from the command line, but when the system is rebooting or shutting down you quickly hit the final “kill everything that still moves and reboot” phase of the process.