Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.unix.shell
Subject: Re: nohup Versus setsid
Date: Fri, 13 Sep 2024 22:32:58 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <vc2eiq$12592$11@dont-email.me>
References: <vbtqcd$2sce$1@dont-email.me>
	<83wmjf1oaq.fsf@helmutwaitzmann.news.arcor.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 14 Sep 2024 00:32:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f0b3208cd64aa384126f587d0af4cdfe";
	logging-data="1119522"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+UFBN97v64KIKp0Ch4Cunv"
User-Agent: Pan/0.160 (Toresk; )
Cancel-Lock: sha1:90bYWlBZnw7a+5FQhdy8aZZtK3k=
Bytes: 2098

On Fri, 13 Sep 2024 19:00:45 +0200, Helmut Waitzmann wrote:

> "nohup" makes the invoked command immune to the HUP signal but lets it
> remain in its terminal session, i. e. the command to be run will not
> lose its controlling terminal.  Thus the other job control signals like
> TSTP, INT, and QUIT sent by the terminal driver to the command may have
> their effects.

See, I always thought the point of that was to allow the job to continue 
after you log off. After all, what was the original meaning of the “HUP” 
(hangup) signal? It meant the modem had disconnected -- the phone line had 
hung up.

> If, on the other hand, you use "setsid", the command to be run will not
> be made immune to any of the job control signals, i. e. any job control
> signal sent to the command to be run by means of the kill(2) system
> call will have its effect.

That’s because setsid starts an entirely new session group, not connected 
to your terminal at all. So it is not vulnerable to any of those remaining 
signals from your terminal, that nohup does not block.

That’s another reason why I think setsid is better than nohup.