在完成中文网站合作开发并将其布署到要服务的生产伺服器时要考量的难题之一是怎样开启须要在伺服器上开启的各种民主化。总之，民主化倒下时也须要重新开启民主化。monit、supervisord和god用于此目地（还有几个其它目地）。但这原因在于对作业控制系统缺乏了解。民主化管理工作是作业控制系统的核心机能。在此项研究中，他们将探讨为何 monit 是严重错误的选择以及恰当的方式是什么。
工艺技术序号 1 调用
恰当的方式是采用作业控制系统的 初始化控制系统，或类似的代替控制系统。init 是在 Unix 上开启时建立的第两个民主化。因而，民主化号为1，大部份先期民主化都成为init民主化的后裔，控制系统开启时开启的大部份民主化都由init开启。增设为复活的民主化也会在它失踪时复活。那么，假如您须要在伺服器上开启两个民主化，将它留下来 init 并非很自然吗？
总之init控制系统老了，也有难题，但杀青过程再有难题，民主化管理工作没难题。然而，这有点麻烦事。有关用语， 参见采用 init JAVA管理工作 Linux 守护者流程。如您所见，这recommend人。
但现在这个调用控制系统将算为。不，它早已从许多 Linux 软件包中消失了。Ubuntu 多年前就早已用upstart替代了init ，其它软件包早已迁移到systemd，最近 Ubuntu 也加入了 systemd 。因而，未来在 systemd 中，假如您须要在伺服器上开启和管理工作民主化，采用 systemd 是标准答案。
从monit已经开始的黑发展史
但为何有init的时候会再次出现monit这样的工具呢？这里有一些发展史。几年前，monit 已经开始在 Ruby on Rails 合作开发人员中大行其道。在 Rails 再次出现以后，Web 合作开发的非主流是 PHP 和 Java，但 PHP 是作为组件附带到 Apache 的，因而不须要原则上管理工作民主化，Java WAS 有他们的民主化管理工作。因而，Web 合作开发人员可能没太多机会考量怎样开启、停用和重新开启伺服器上的民主化。助推当时 Web 合作开发时代的并并非以后沉迷 Unix/Linux 的骇客。
在这种情况下，Rails 问世了，但没可以运行 Rails 的应用伺服器，因而Ruby 合作开发人员他们做了两个像mongrel一样的伺服器。但，像Java WAS那样合作开发加装整个民主化管理工作机能并不容易（总之，这并非两个好方式），而且由于Rails还不如稳定，绵羊民主化经常倒下。于是萌发了监视民主化的设想，看是并非倒下了，死了就留存，结果是monit。monit 之因而盛行，原因在于它改善了 Rails + mongrel 女团的复杂性。
难题是，正像他们以后看到的，他们不须要 monit，因为他们早已有两个用于此目地的 init 控制系统。显而易见的是ReinventTheWheel。总之，轮子可以通过改进它来重新发明。但，monit 比 init 更慢、更消耗资源且更不稳定。 在 running-processes 中，表示如下。
“Wow. You reinvented initand cron, but managed to make them both less reliable and consume more CPU than I could’ve imagined.”监视的接口
但 monit 一定有话要说。当时upstart还处于起步阶段，没systemd，init的难题早就被指出了（不管是并非民主化管理工作）。而且，init的增设方式也远非Ruby合作开发人员的口味。正像您在采用 init JAVA管理工作 Linux 守护者民主化中看到的那样，/ etc/init.d 中的JAVA并非很漂亮。这可能与 喜欢ReinventTheWheel的 Ruby 合作开发人员的倾向一致。
并且 monit 有两个 init 没消化的函数。当民主化终止时，它会通过电子邮件等方式发送通知（总之，这并非不可能，但至少它不是 init 的机能）。这两个至少是监视的借口。
Unix哲学
然而，这个借口是不如的。Unix 软件反映了与一般用户采用的软件不同的哲学。与服务于多种用途的用户应用流程不同，Unix 流程不服务于多种用途，它们只做一件事，但旨在最好地完成工作。通过管道、重定向和信号等基本方式女团这些流程，您可以做复杂的事情。但，monit 结合了在民主化失踪时恢复民主化并通知合作开发人员的任务。当时Unix早已有很多比较好的监视工具，因而monit的监视机能并并非很好。因而，我把这两个工作放在一起，这两个工作都比最初存在的其它工具更糟糕。因而，在您想要击败这两个目标的情况下，有一些优势，但作为回报，您会采用大量控制系统资源并获得更差的监视服务。
但，假如 monit 只专注于通过专注于 Unix 哲学来管理工作流程，就像我以后所说的那样，它就变成了两个完整的 ReinventTheWheel，毫无用处。Supervisord 是这样。supervisord 是 init 机能的两个子集，但在较低的性能水平上，它是纯粹的、纯粹的盈余。
上帝比monit走得更远。它有许多强大的机能，因而很难将它们与 monit 或 supervisord 捆绑在一起。因而，假如您专注于流程管理工作以外的目地，那么您可能会接受它，但这提出了两个难题，因为仍有许多更好的工具。
此刻回答
upstart
尽管早已决定过渡到 systemd，但许多发行版仍然默认提供 upstart。您仍然可以采用 systemd，但现在，您可以简单地继续采用基本的 upstart 并应用 systemd，同时应用 systemd 更改为默认值的软件包。那么，让我们来简单看看怎样采用 upstart。
upstart/etc/init可以通过在 . 他们来看两个celery的例子，它被广泛用作任务队列。celery 伺服器通常采用以下命令开启。
这将开启两个处理工作的工作民主化。假如你想用 upstart 管理工作它，请/etc/init/celery.conf按如下方式建立文件。
与 init 不同，您不须要授予执行权限。然后像这样开启伺服器：
关机和重启如下。在Ubuntu的情况下，它很方便，因为它会通过按Tab键自动完成可以启动哪些服务。
在上面的配置文件中，respawn部分是死后要再次执行的增设。失踪后，以 5 秒间隔已经开始重试，最多 10 次。在JAVA部分编写要实际执行的代码。
两个警告是，与 cron 类似，不会加载环境变量。假如依赖locale等环境变量，则必须指定LC_ALL等环境变量。
控制系统
假如说新贵是现在，那么 systemd 是未来。由于未来大多数Linux软件包都会集成到systemd中，因而提前学习systemd会很好。总之，即使是现在，即使 systemd 并非默认的，大多数最新的软件包也会加装，即使没加装，它也会作为包加装。假如你看一下 sshd 的例子会更容易理解。在Ubuntu软件包中， /etc/systemd/system/sshd.service文件是这样写的：
开启、重启等。
为何社区选择 systemd
但，为何 init 的代替方案 upstart 早已问世并经过多年验证，但为何 systemd 再次出现并取而代之？总之，推动暴发户的 Ubuntu 并不想转用 systemd，但Ubuntu 的母体 Debian 社区决定转用 systemd，因而 Ubuntu 也顺势而为。那么，upstart 尝试改进 init 的哪些方面，systemd 不喜欢 upstart 的哪些方面？
init 的最大缺点是任务并行运行。因而，假如有很多 I/O 作业，开启速度会很慢。因而，upstart 是基于事件编写的，并异步处理任务。并且比起sysv init，它更容易增设。根据我的经验，它比 systemd 更容易，但在这一点上似乎存在分歧。
然而，随着这个新贵遍布多个软件包，它已经开始受到批评。其中，最详细的解释是Rethinking PID 1。在本文中，他们首先定义了两个好的 init 控制系统应该具有以下特征。
少已经开始尽可能并行处理但upstart是可以增设依赖的，因而假如服务之间增设了依赖，是按照依赖的先后顺序执行的。最多应用异步逻辑，但最终须要序列化，这降低了性能增益。并且，由于不立即须要的服务也被上传，因而从一已经开始就会再次出现许多民主化。另一方面，systemd 可以按需运行许多服务。例如，sshd 在开启时不会开启，而是在向端口 22 发出请求时开启。依赖也是这样增设的。因而，开启速度快，不增加不必要的服务，节省控制系统资源。从管理工作应用伺服器民主化的角度来看，节省控制系统资源也是有益的。从这个角度来看，monit 和 supervisord 仍然是多余的。
辩论 init system提供了 init、systemd 和 upstart 的详细比较，因而阅读本文会很有趣。
追求正确的方式
前面解释了monit再次出现的发展史背景。但，我想向前迈进，探讨态度难题。为何 monit 或 supervisord 合作开发人员会不理会 init 并合作开发这样的东西？我认为这是解决难题的优先事项。假如你只专注于解决眼前的现状，就会想到这样的解决方案。monit 合作开发人员在遇到的情况下问了哪些难题？可能并非开启 unix 民主化的恰当方式。是并非更像是怎样确定两个民主化是否正在运行，或者怎样重新生成民主化？因而，收集此类难题的个人标准答案将有助于合作开发 monit。手头的难题就这样解决了。欢呼。
我认为这是工程师的态度难题。工程师本能地专注于解决他们面前的难题。这是个好姿势。然而，它不应该止步于此。尽管如此，您仍必须继续怀疑并思考什么是恰当的做法。假如您查看与 monit 或 supervisord 相关的难题，您会发现两个有趣的事实。这意味着 monit 他们的民主化必须在采用 monit 开启的进程以后浮动。那么我怎样保持 supervisord 浮动？同样的难题经常再次出现。因为你不能让 supervisord 作为 supervisord 浮动。假如你仔细想想，即使你不知道init， 你也能猜到OS中一定有什么东西在开启两个民主化中起作用。并且 init 或 upstart 总是在标准答案中运行，因而查看标准答案，您可能会认为让 supervisord 完成 init 或 upstart 的工作是可以的。但为何他们不能想到这个设想呢？这原因在于重点只放在手头的任务上。假如我退后一步，有时间思考，supervisord 就不会来了。
对于那些了解我的设想，坚持精益创业并强调专注于手头任务的人来说，追求这种 恰当的方式可能看起来很尴尬。但恰当的方式是恰当的方式，因为它更有效率。假如主管合作开发人员考量一下恰当的方式是什么，而并非尝试通过他们合作开发来解决难题，他们会更快地解决难题，因为他们在执行时只须要建立两个简单的配置文件。合作开发 supervisord，解决方案的质量也会好得多。
一直专注于解决当前难题的合作开发人员积累了奇怪的诀窍，因而往往很难通过留下简单的方式而采用困难的方式来维护，或者通过他们的库解决难题。另一方面，一直在追求恰当方式的合作开发人员 通常会选择更简单、更高效的方式，因为他们了解平台的特性并尊重约定 。让monit、supervisord、god流入发展史，作为审判之石。
