守护进程和正常进程之间的行为差​​异是什么?

时间:2010-08-31 20:13:49

标签: operating-system process daemon

我知道守护进程主要在后台运行,即它们需要用户进行非常少的交互。

Wikipedia lists通常存在的一些守护进程类型:

  • 与控制tty分离
  • 成为会议负责人
  • 成为流程组负责人
  • 通过分叉和退出(一次或两次)保持在后台。有时需要将此过程成为会话负责人。它还允许父进程继续正常执行。这个成语有时用短语“fork off and die”
  • 来概括
  • 将根目录(“/”)设置为当前工作目录,以便进程不会保留可能位于已装入文件系统上的任何正在使用的目录(允许将其卸载)。
  • 将umask更改为0以允许open(),creat()等。调用提供自己的权限掩码,而不依赖于调用者的umask
  • 关闭执行时由父进程保持打开的所有继承的打开文件,包括文件描述符0,1和2(stdin,stdout,stderr)。所需文件将在稍后打开。
  • 使用日志文件,控制台或/ dev / null作为stdin,stdout和stderr

  

我想知道守护进程中的行为是否与正常进程有区别,除了我在第一行中提到的那个。这两种流程都可以完成工作,并根据用户完成工作所需的交互量与用户进行交互。

守护进程还有更多吗?

3 个答案:

答案 0 :(得分:27)

不是真的。守护程序只是一个连续运行且通常不附加到终端的进程的术语。

守护进程不是一个单独的进程类,它们没有特殊的权限或属性。

有一个名为daemonman page)的BSD / Linux C函数,但这只是将进程从终端分离的简单方法。之所以如此命名,是因为守护进程通常会做的,而不是相反。

答案 1 :(得分:8)

进程守护程序之间的主要区别在于守护进程的父级是 init - 在* Nix启动期间启动的第一个进程。这就是守护程序未连接到终端的原因。因此,当您关闭终端时,它不会被操作系统杀死。但您仍然可以向守护程序发送信号。

答案 2 :(得分:1)

问题有点模糊,但无论如何我都会尝试:

从技术上讲,守护进程就像其他进程一样。他们通常(但不是必须)关闭misc文件描述符,并且其他行为适合长期存在的进程。有关如何设置大多数守护程序进程的高级别(在Python中),请查看: http://www.noah.org/wiki/Daemonize_Python

因此差异真正归结为生命周期和用户。守护进程长时间处理,通常与给定的运行级别一样长。它们通常还为其他系统范围的流程或比平均用户运行流程更高的流程提供服务。