As SIGTERM doesn't gracefully shutdown the server, my team and I decided to write the stop command to the stdin (Docker environment). We are looking forward to an update on this issue, handling SIGTERM gracefully would be great.

It would be rather nice to have Spigot intercept SIGTERM and call whatever code is needed for `/stop`. One of the issues that my team and I are facing now is that we're starting spigot as a child process without the ability to invoke any commands against it as well as are unable to use RCON. Right now to terminate it we're working around this by having a plugin listen over a Unix socket for commands, which isn't ideal. 

In my opinion it is very important to handle SIGTERM like /stop. This makes it possible to run Spigot servers in docker containers without risking data loss. When a docker container is stopped, it sends SIGTERM to the application running in the container and expects it to gracefully stop. Almost every other application properly shuts down on a SIGTERM signal because it expects to run as a daemon where the only way to stop it is sending a kill signal.

Java only supports signal handling via shutdown hooks

https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)

SIGTERM (sent by `kill pid` or daemon management system), SIGINT (sent by the console on Ctrl + C) and SIGQUIT (sent by the console on Ctrl + ) all have notionally different behaviours. These signals are poorly defined, dating back to the POSIX standard, but it is expected that modern daemons will shutdown on SIGTERM without losing data. I appreciate the argument that SIGINT is a more aggressive signal, given it stands for 'interrupt' and applications like Python respond to it by stalling execution immediately (a 'SIGKILL' for the underlying program, and graceful cleanup for the runtime).

If I had to order the signals: SIGKILL (OS is intervening) > SIGQUIT (software stalled, please stop and core dump) > SIGINT (software stalled, please stop) > SIGTERM (please save state and shutdown) > SIGHUP (originally terminal gone away, now often reload configuration)

If Spigot connected SIGTERM to /stop and SIGINT to "abrupt path to halt, saving world data but little else", that would be logical from my point of view. Happy to look into submitting a patch if we come to some conclusion.

Its not designed to be the same as /stop - its meant to be more aggressive so ctrl+c can be used to at least have a chance of saving data in a stuck server.

I accept that there is a bug in that as of 1.14 ctrl+c can hang the server and fail to shut it down, but it is not meant to be a "graceful shut down" - that's what /stop is for.