Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lawrence D'Oliveiro 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: References: <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.