从init.d到upstart，有桥吗？
我有一个非常好的脚本可以在/etc/init.d中使用。 事实上，我有很多这些，都是用Tanuki Java Service Wrapper创建的。
在我看来，可能有一个简单的模板用于将这样的shell脚本包装为upstart脚本，但是一些谷歌搜索并没有透露一个。
我错过了什么吗？
我不记得看到这个模板了。 然而，从技术上讲，由于向后兼容性工作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脚本魔法可以反复重复。 案例陈述，pidfile跟踪，lsb评论行。 如何在没有读取的情况下编写GOOD init.d脚本并不是很清楚。
如果你已经完成了编写所有这些的麻烦，那么你就不需要新手工作，除非我在另一篇评论中提到过，你依赖于另一个新贵的工作/事件。
但实际上，新贵确实让事情变得非常简单。 除非您需要设置tmpdirs，ulimits或运行时参数，否则您不需要预先启动。 你不应该需要一个后停站，除非你想确保你在服务后整理（服务真的应该在正常退出后自行清理）。
通常情况下，具有许多选项的巨型init.d脚本可归结为10-15行的新手工作。 最复杂的init.d脚本可以将大部分逻辑转储到pre-start中。 关键是它只需要一小段代码来设置进程的环境，而不是处理start / stop / respawn / etc的逻辑。
最困难的部分，也就是人们最常犯错的部分，就是知道何时开始/停止工作。 start on runlevel [2345]似乎是合乎逻辑的，但忽略了网络在此时并行发生的事实，就像本地文件系统挂载一样。 关键是要试着找出你需要的最小的东西（其他服务，文件系统，网络等）才能运行，并在完成这些工作后开始。 大多数传统网络服务应该start on (local-filesystems and net-device-up IFACE!=lo) 。
我认为Upstart保持与/etc/init.d SysV样式的init脚本的向后兼容性。 您应该能够只使用您的init脚本。