作为会话领导者的rsyslogd

Question

我目前正在阅读Unix环境中的高级编程。在其中一个练习中，它说：

唯一不是会话领导者的用户级守护进程是rsyAdd.1-d进程。解释为什么syslogd守护进程不是会话领导者。

但是，当我亲自验证时，我看到在我的系统(Linux4.4)上，它确实是一个会话领导者(因为PID == SID)：

UID        PID  PPID  PGID   SID  CMD
syslog    1171     1  1171  1171  /usr/sbin/rsyslogd -n

这是系统问题吗？这本书中的一些信息已经过时了，因为每个人都加入了系统潮流，而它主要谈论的是经典的System init。或者他们只是改变了它的工作方式？

这本书显然想说明为什么它是不同的，所以如果有人知道为什么历史上它不再是一个会议领袖，为什么现在是这样，那就太好了。

Answer 1

编辑

实际上，我看过一个运行rsyAdd.1-d4.2.0的旧的ubuntu10.04系统。

它根本没有调用setsid() (因此从执行它的进程继承了sid )，而是调用了它(这里是从strace输出)：

 19391 open("/dev/tty", O_RDWR|O_LARGEFILE|O_CLOEXEC) = 0
 19391 ioctl(0, TIOCNOTTY)               = 0

与终点站分离。

看看源代码，它只在没有设置HAVE_SETSID时才这样做。很明显，Linux已经拥有了setsid()，并且已经使用了几十年，所以有一些问题。

现在，更多地查看源代码，这只是构建过程从不设置HAVE_SETSID，因为它一开始就不检查setsid()的支持。

错误(错误：setsid在autoconf文件中拼写为setid )是2013年年固定 (第一次发布在rsyAdd.1-d7.5.3中)。

(顺便说一句，参见旧代码中的TODO关于HP/UX的章节，它显示作者已经意识到出了问题(但直到很久以后才开始调查)。

将原始答案保存在下面，因为人们可能会发现其中的信息很有用。

胡思乱想：

如果您是会话领导者，并且在没有tty标志的情况下打开O_NOCTTY设备，那么您将成为终端的控制过程。

这就是为什么当尝试执行一个应用程序(如果不是设计为作为守护进程运行)以便它作为守护进程运行时，建议在执行应用程序之前在setsid()之后执行另一个分支，以确保进程在出于某种原因打开tty设备时不会无意中成为终端控制器。

syslogd通常会打开tty设备来发送用户消息，所以这可能就是为什么您的书中说syAdd.1-d不是会话的领导者，它描述了从O_NOCTTY标志不存在的时候起的syAdd.1-d实现的行为(尽管这个标志至少从80年代后期就已经存在了)。

另一种方法是syAdd.1-d确保它打开的所有文件都是用O_NOCTTY打开的，这可能就是您的rsyslogd (与systemd无关)所做的。