私は現在、「Unix環境の高度なプログラミング」を読んでいます。練習の1つでは、次のように言います。
セッションリーダーではなく、唯一のユーザーレベルのデーモンプロセスはrsyslogdプロセスです。 syslogdデーモンがセッションリーダーではない理由を説明してください。
しかし、これを直接確認しに行ったとき、私のシステム（Linux 4.4）はこれが実際にセッションリーダーであることを発見しました（PID == SIDなので）。
UID PID PPID PGID SID CMD
syslog 1171 1 1171 1171 /usr/sbin/rsyslogd -n
これはシステム的なことですか？誰もがsystemd便乗したので、この本の情報のいくつかは少し古い情報であり、主に古典的なSystem V initについて議論します。または、動作方法を変更した可能性があります。
この本は明らかになぜそれが違うのかを見せたいので、歴史的になぜ過去にカンファレンスホストになっていないのか、そしてなぜ今なのか知っている人がいるのなら良いでしょう。
ベストアンサー1
編集する
私は実際にrsyslogd 4.2.0を実行している古いUbuntu 10.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()
エラー（タイプ：setsidautoconfファイルにスペルがある）は次のとおりです。setid2013年に修理(rsyslogd 7.5.3で初めてリリース)
（ところで、参照太陽HP/UXについて前のコードは、作成者が問題があることを知っていたことを示しています（ただし、それ以降は調査しません）。
人々は情報が役に立つと思うかもしれませんので、以下に元の答えを残してください。
おおよその推測:
セッションリーダーでフラグなしttyでデバイスを開くと、端末を制御するプロセスになります。O_NOCTTY
setsid()そのため、アプリケーション（デーモンとして実行するように設計されていない）を実行してデーモンとして実行しようとするときは、プロセスが誤ってデーモンプロセスにならないように実行する前に別のフォークを実行することをお勧めします。 。ターミナルコントローラ（何らかの理由でttyデバイスが開いている場合）。
syslogd通常、ttyデバイスはユーザーメッセージを送信するために開かれているため、本ではsyslogdがセッションリーダーではないと言い、O_NOCTTYフラグがない場合のsyslogd実装の動作について説明します（少なくとも2000年以降はフラグが使用されています）。 1980年代）以降）。
別のアプローチは、syslogdで開かれたすべてのファイルがO_NOCTTYで開かれていることを確認することです。これはおそらくユーザーが実行するタスクrsyslogd（およびそれとは関係のないタスクsystemd）です。