Type in the conditions and the executable name, and systemd will handle its starting, stopping and who knows what else. Like it's all systemd needs to monitor the daemon.

I see that an average systemd service basically consists of some requirements and ExecStart. Apparently, systemctl just makes the simplest unit file possible on its own, and hopes it will suffice! Now I'm wondering if systemd is actually incapable of handling such complex situations at all! I've started to look for information about how systemd is better than sysV, and what can I do to simplify and empower everything. It doesn't start properly, it doesn't stop properly, it does not display status properly, not to mention the absence of the 'command' command. 'Well,' I thought, 'now it's recognized by systemd, and now I can control it via systemctl - and it should probably just use my old script to process the commands!' And turns out I was very much wrong. I remember having problems with some startup scripts before apparently, just putting a script into /etc/init.d and marking it executable is no longer enough - I had to 'enable' them in order to make them work. I remember systemd developers promising that 'old sysV scripts will just work as they did before', but turns out it's not so easy! Still, I'm actually very supportive of systemd - it really looks like a lot of improvement, simplification and centralization. But for now, I keep my old-style script because it's awesome.

Now I've upgraded to Debian Jessie, which has systemd. It can even pass a command to Minecraft with /etc/init.d/minecraft command - this is useful for scheduled backups. It is a very good script it runs Minecraft in a 'screen' it can ensure Minecraft is never started twice and it waits for Minecraft to shut down when stopped. I've been running a Minecraft server with a sysV init script.

Minecraft server jar not working