我有一个非常好的脚本可以在 /etc/init.d 中使用。事实上，我有很多它们，都是用 Tanuki Java Service Wrapper 创建的。
在我看来，可以有一个简单的模板来将这样的 shell 脚本包装成一个新贵脚本，但一点谷歌搜索并没有揭示一个。
我错过了什么吗？
我不记得看到过这个模板。然而，有点讽刺的是，从技术上讲，由于向后兼容的工作 rc 和 rcS，它的暴发户首先启动了你的 init.d 脚本。
我会考虑将您拥有的任何内容重写为新贵的工作，但是，我知道有些脚本很难转换，所以这是我对一些脚本所做的一段时间：
description "xyz"
author "xyz"
start on runlevel 5
stop on runlevel [!5]
pre-start script
# do my work here to start the service
end script
post-stop script
# do work here to stop the service
end script
现在，根据服务的性质，无论是持续存在还是分叉自身，您可能需要将expect fork或添加task到作业文件中。
只是为了完成这个想法，通常，这就是一个完整的新贵工作文件的全部内容。所有的启动前工作都完成了，所有的清理工作都完成了，唯一剩下的就是服务本身，它通常添加：
exec service_cmd
因此，新贵工作的一个要点是易于编写。
init.d 脚本中有很多 shell 脚本魔法，它们会一遍又一遍地重复。Case 语句、pidfile 跟踪、lsb 注释行。它不是很清楚如何在没有阅读的情况下编写一个好的 init.d 脚本。
如果你已经经历了写所有这些的麻烦，那么你不需要一个暴发户的工作，除非，正如我在另一条评论中提到的，你依赖另一个暴发户的工作/事件。
但实际上，新贵确实让事情变得非常简单。除非您需要设置诸如 tmpdirs、ulimits 或运行时参数之类的内容，否则您不需要预先启动。除非您想确保在服务后进行整理（服务确实应该在正常退出后自行清理），否则您不需要 post-stop。
很多时候，一个带有许多选项的巨大 init.d 脚本归结为一个 10 - 15 行的新贵工作。最复杂的 init.d 脚本可以将它们的大部分逻辑转储到 pre-start 中。关键是它只是一小段代码来设置进程的环境，而不是处理启动/停止/重新生成/等的逻辑。
最难的部分，也是人们最常犯错的部分，是知道何时开始/停止他们的工作。start on runlevel [2345]似乎合乎逻辑，但忽略了网络在此时并行运行的事实，本地文件系统安装也是如此。关键是要尝试找出运行所需的最少东西（其他服务、文件系统、网络等），并在完成后开始。大多数传统网络服务都应该做start on (local-filesystems and net-device-up IFACE!=lo)。