我一直在运行带有 sysV init 脚本的 Minecraft 服务器。这是一个非常好的脚本；它在“屏幕”中运行 Minecraft；它可以确保 Minecraft 永远不会启动两次；它会等待 Minecraft 在停止时关闭。它甚至可以向 Minecraft 传递命令/etc/init.d/minecraft command <command>——这对于计划备份很有用。
现在我已经升级到 Debian Jessie，它有 systemd。但是现在，我保留我的旧式脚本，因为它很棒。尽管如此，我实际上非常支持 systemd - 它看起来确实有很多改进、简化和集中化。我记得 systemd 开发人员承诺“旧的 sysV 脚本会像以前一样工作”，但事实证明这并不容易！
我记得之前有一些启动脚本有问题；显然，仅仅将脚本放入 /etc/init.d 并将其标记为可执行已经不够了 - 我必须“启用”它们才能使它们工作。“好吧，”我想，“现在它被 systemd 识别了，现在我可以通过 systemctl 来控制它——它可能应该只使用我的旧脚本来处理命令！” 事实证明我错了。
它不能正常启动，不能正常停止，不能正常显示状态，更不用说缺少“命令”命令了。我已经开始寻找有关 systemd 如何比 sysV 更好的信息，以及我可以做些什么来简化和增强一切。显然， systemctl 只是自己制作了最简单的单元文件，希望它就足够了！现在我想知道 systemd 是否真的无法处理如此复杂的情况！
我看到一个普通的 systemd 服务基本上由一些要求和 ExecStart 组成。就像 systemd 需要监视守护进程一样。输入条件和可执行文件名称，systemd 将处理它的启动、停止以及其他事情。但是没那么容易！！你不能只是杀死 Minecraft 的 PID（更不用说它与屏幕的 PID 不同）！我想为每个动作编写更复杂的脚本，甚至可能添加像“命令”这样的新动作（好吧，我已经接受了这可能根本不可能）。对于“状态”，它必须监视 Java 进程，对于停止，它必须向 Minecraft 控制台发送命令，然后等待 Java 和屏幕都死掉！我还想确保 systemd 不会只是尝试 SIGHUP 或 SIGINT 或 SIGTERM 它！
那么，真正允许我们利用 systemd 为我们提供的所有“改进”和“简化”的巧妙、现代、“预期的 systemd 方式”是什么？当然，它应该能够处理比在一行中启动并用 SIGINT …