docs(daemon): copy tweaks to comment

Commit `fa93c35`

Eric Bower · 2026-07-30 16:42:14 -0400 EDT

parent a39b3d0

docs(daemon): copy tweaks to comment

1 files changed, +8, -11

M src/daemonize.zig

+8, -11

......@@ -122,10 +122,9 @@ pub fn spawnPty(sesh_name: []const u8, cmd: Cmd) !PtyInfo {
///
/// When launching a daemon, you normally set the child process of the fork to
/// be the session leader via setsid() which creates a new session that removes
/// the current controlling terminal but creates the authority to grab a new
/// one. This is important because we don't want a controlling terminal for our
/// daemon or else our daemon could receive signals to shutdown when the
/// controlling terminal closes.
/// the current controlling terminal. This is important because we don't want a
/// controlling terminal for our daemon or else it could receive signals to
/// shutdown when the controlling terminal closes.
///
/// However, if the first fork's child process is also the daemon process, then
/// it's technically possible for the daemon to open a terminal device (e.g.

......@@ -134,14 +133,12 @@ pub fn spawnPty(sesh_name: []const u8, cmd: Cmd) !PtyInfo {
/// terminal-generated signals (e.g. SIGINT) or SIGHUP from terminal disconnect
/// which could kill the daemon.
///
/// The first fork isn't arbitrary either: setsid() fails with EPERM if the
/// caller is already a process group leader, which a process launched directly
/// from a shell typically is. The first fork produces a child guaranteed not
/// to be a group leader, so setsid() will succeed.  By forking a second time,
/// the grandchild process (the daemon) is not the session leader. Per POSIX,
/// only a process that is the session leader can acquire a controlling terminal.
/// The first fork produces a child guaranteed not to be a group leader, so
/// setsid() will succeed.  By forking a second time, the grandchild process
/// (the daemon) is not the session leader. Per POSIX, only a process that is
/// the session leader can acquire a controlling terminal.
///
/// Apparently this is "a bit paranoid," and on Linux it is arguable since a
/// Apparently this is "a bit paranoid" and on Linux it is arguable since a
/// session leader only acquires a controlling terminal under
/// implementation-defined conditions. But the double-fork is the portable way
/// to guarantee the daemon can never acquire one, regardless of how a given

...	...		@@ -122,10 +122,9 @@ pub fn spawnPty(sesh_name: []const u8, cmd: Cmd) !PtyInfo {
122	122		///
123	123		/// When launching a daemon, you normally set the child process of the fork to
124	124		/// be the session leader via setsid() which creates a new session that removes
125		-	/// the current controlling terminal but creates the authority to grab a new
126		-	/// one. This is important because we don't want a controlling terminal for our
127		-	/// daemon or else our daemon could receive signals to shutdown when the
128		-	/// controlling terminal closes.
	125	+	/// the current controlling terminal. This is important because we don't want a
	126	+	/// controlling terminal for our daemon or else it could receive signals to
	127	+	/// shutdown when the controlling terminal closes.
129	128		///
130	129		/// However, if the first fork's child process is also the daemon process, then
131	130		/// it's technically possible for the daemon to open a terminal device (e.g.

...	...		@@ -134,14 +133,12 @@ pub fn spawnPty(sesh_name: []const u8, cmd: Cmd) !PtyInfo {
134	133		/// terminal-generated signals (e.g. SIGINT) or SIGHUP from terminal disconnect
135	134		/// which could kill the daemon.
136	135		///
137		-	/// The first fork isn't arbitrary either: setsid() fails with EPERM if the
138		-	/// caller is already a process group leader, which a process launched directly
139		-	/// from a shell typically is. The first fork produces a child guaranteed not
140		-	/// to be a group leader, so setsid() will succeed. By forking a second time,
141		-	/// the grandchild process (the daemon) is not the session leader. Per POSIX,
142		-	/// only a process that is the session leader can acquire a controlling terminal.
	136	+	/// The first fork produces a child guaranteed not to be a group leader, so
	137	+	/// setsid() will succeed. By forking a second time, the grandchild process
	138	+	/// (the daemon) is not the session leader. Per POSIX, only a process that is
	139	+	/// the session leader can acquire a controlling terminal.
143	140		///
144		-	/// Apparently this is "a bit paranoid," and on Linux it is arguable since a
	141	+	/// Apparently this is "a bit paranoid" and on Linux it is arguable since a
145	142		/// session leader only acquires a controlling terminal under
146	143		/// implementation-defined conditions. But the double-fork is the portable way
147	144		/// to guarantee the daemon can never acquire one, regardless of how a given

Commit fa93c35

Commit `fa93c35`