nginx守护进程开/关选项有什么区别？
这是我的第一次web服务器管理经验，我想构建使用nginx作为web服务器的docker容器。在所有docker教程中daemon off选项放入main。conf文件，但省略了有关它的说明。
我在网上搜索了一下，不明白< code>daemon有什么区别；和< code >守护程序关闭；选项。有人提到< code >守护进程关闭；是为了生产，为什么？
你能解释一下，这两个选项有什么区别，为什么我应该在生产中使用daemon off；？
共有2个答案
正如这个SO线程中提到的，似乎“初始进程立即生成了一个主nginx进程和一些工作线程，然后退出。由于 Docker 只监视原始命令的 PID，因此容器会停止。
关于daemon off指令，它似乎最初用于nginx代码开发，但根据常见问题解答，它对于1.0.9版后的生产是安全的。
对于正常生产（在服务器上），使用默认的daemon on；指令，以便Nginx服务器将在后台启动。通过这种方式，Nginx和其他服务正在运行并相互通信。一台服务器运行许多服务。
对于 Docker 容器（或用于调试），守护程序 off; 指令告诉 Nginx 留在前台。对于容器，这很有用，因为最佳实践是针对一个容器 = 一个进程。一个服务器（容器）只有一个服务。
正在关闭< code >守护程序；在有Supervisor等第三方工具控制您的服务时也很有用。Supervisor允许你一次停止/启动/获取一系列服务的状态。
我使用<代码>守护进程关闭；调整我的Nginx配置，然后干净利落地终止服务并重启它。这让我可以快速测试配置。完成后，我使用默认的< code >守护进程；。
-
维基百科中守护进程的解释 守护进程是一个运行后台进程, 非交互式用户直接控制的在计算机程序 Gradle 守护进程是一个后台进程, 它运行着繁重的构建, 然后在构建等待下一次构建的之间保持自身存在. 这使得数据和代码在下一次构建前已经准备好,并存入内存中. 这显著的提高了后续构建的性能. 启用Gradle守护进程是一种节约构建时间的廉价方式. 强烈建议在所有开发机器上启用Gradle的守护进程.但
-
建议在开发环境中使用Gradle的守护进程,不建议在持续集成环境和构建服务器环境中使用守护进程. 守护进程可以更快的构建,这对于一个正坐在椅子前构建项目的人来说非常重要.对于CI构建来说,稳定性和可预见性是最重要的.为每个构建运行时用一个新的,完全孤立于以前的版本的程序,更加可靠。
-
如何确定我的 Gradle 守护进程死亡的原因？我收到的唯一消息是L 这发生在活动版本中。几个步骤将完成，一个步骤将显示为活动状态，然后生成失败。 这是在将我们的内存参数(< code > Xmx < code > Xms < code > perm gen )从一个调用< code>gradlew的shell脚本移动到< code>gradle.properties并直接调用< code>gra
-
守护(Daemon)进程 我们可以认为守护进程就是后台服务进程，因为它会有一个很长的生命周期提供服务，关闭终端不会影响服务，也就是说可以忽略某些信号。 实现守护进程 首先要保证进程在后台运行，可以在启动程序后面加&，当然更原始的方法是进程自己fork然后结束父进程。 if (pid=fork()) { exit(0); // Parent process } 然后是与终端、进程组、会话(Ses
-
Daemonset可以确保全部（或者某些）节点上运行一个Pod的副本。 Daemonset可以确保全部（或者某些）节点上运行一个Pod的副本。当有节点加入集群时，也会为他们新增一个Pod。当有节点从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。 Daemonset典型用法如下： 在每个节点上运行集群存守护进程 在每个节点上运行日志收集守护进程 在每个节点上运行
-
建议使用 systemd 管理我们的服务进程。 可以参考swoole官方文档 使用方法 请确保cabal.php配置文件中的swoole.daemonize配置为关闭状态（0或false）！ 'swoole' => [ // ... 'daemonize' => 0, // ... ], 在 /etc/systemd/system/目录中，创建一个 cabal.