| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 108:30:18 |
| Calls: | 290 |
| Files: | 905 |
| Messages: | 76,683 |
It has long seemed to me that nohup(1) was an old, hacky way of doing
what can be done more elegantly using setsid(1). Compare the docs for >yourself <https://manpages.debian.org/1/nohup.1.en.html> vs ><https://manpages.debian.org/1/setsid.1.en.html>, and tell me why we
still need nohup when we have setsid?
In article <vbtqcd$2sce$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
It has long seemed to me that nohup(1) was an old, hacky way of doing
what can be done more elegantly using setsid(1). Compare the docs for
yourself [...], and tell me why we still need nohup when we have setsid?
First, I do get what you're saying - and I've both A) Used setsid(2) a lot over the years so am familiar with it and B) Always thought that nohup(1)
was old and crusty. I cringe whenever I hear people recommend it in help groups nowadays.
That said, it is kind of apples-to-oranges comparison. nohup(1) is more of
a command, while setsid(1) is really just a thin wrapper around the system call. According to the man page, nohup(1) does a lot of things, including setting up logging and so on; there is no underlying system call. OTOH, to understand setsid(1), you really have to understand the underlying system call - and that system call is not simple. It (setsid(2)) is kind of a "bigger/better" version of setpgrp() and it has some interesting
restrictions on its use. In a way, it could be said that both sessions and process groups were only implemented to support shell job control, and this is kind of a funny thing, since shell job control is now sort of thought of as an anachronism (I still use it, but I seem to be in some kind of minority).
So, despite what I said 2 paragraphs ago, nohup(1) may be better as a recommendation to the newbie.
It has long seemed to me that nohup(1) was an old, hacky way of doing
what can be done more elegantly using setsid(1). Compare the docs for yourself <https://manpages.debian.org/1/nohup.1.en.html> vs
<https://manpages.debian.org/1/setsid.1.en.html>, and tell me why we
still need nohup when we have setsid?
In article <vbtqcd$2sce$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
It has long seemed to me that nohup(1) was an old, hacky way of doing
what can be done more elegantly using setsid(1).
I don't know the details, but the descriptions look quite different...
nohup - run a command immune to hangups, with output to a non-tty
setsid - run a program in a new session
On Thu, 12 Sep 2024 22:02:10 -0000 (UTC), Lawrence D'Oliveiro wrote:
The effect is supposed to be the same: spawn a background task that
will continue running after you log out.
That's not the only thing that the (POSIX) nohup(1) tool does.
Then I can watch for status without flooding the terminal:
On Thu, 12 Sep 2024 14:01:37 +0200, Janis Papanagnou wrote:
In article <vbtqcd$2sce$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
It has long seemed to me that nohup(1) was an old, hacky way of doing
what can be done more elegantly using setsid(1).
I don't know the details, but the descriptions look quite different...
nohup - run a command immune to hangups, with output to a non-tty
setsid - run a program in a new session
The effect is supposed to be the same: spawn a background task that will continue running after you log out.
On Thu, 12 Sep 2024 22:02:10 -0000 (UTC), Lawrence D'Oliveiro wrote:
On Thu, 12 Sep 2024 14:01:37 +0200, Janis Papanagnou wrote:
In article <vbtqcd$2sce$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
It has long seemed to me that nohup(1) was an old, hacky way of doing
what can be done more elegantly using setsid(1).
I don't know the details, but the descriptions look quite different...
nohup - run a command immune to hangups, with output to a non-tty
setsid - run a program in a new session
The effect is supposed to be the same: spawn a background task that will
continue running after you log out.
That's not the only thing that the (POSIX) nohup(1) tool does.
I prefer the simplicity of nohup's behavior, and use it when doing
"big" compiles.
I have a script:
$ cat go.sh
time -p make -j64
So I can:
$ nohup ./go.sh &
Then I can watch for status without flooding the terminal:
$ while : ; do tail nohup.out ; date; sleep 5 ; done
Everybody has their own way of doing things, but this works
on any POSIX system, not just Linux[*].
On Thu, 12 Sep 2024 23:07:07 -0000 (UTC), vallor wrote:
On Thu, 12 Sep 2024 22:02:10 -0000 (UTC), Lawrence D'Oliveiro wrote:
The effect is supposed to be the same: spawn a background task that
will continue running after you log out.
That's not the only thing that the (POSIX) nohup(1) tool does.
Then I can watch for status without flooding the terminal:
But then, you cannot do more than one nohup invocation at a time, if one
is already writing to nohup.out.
With setsid, I just specify an output log file for each invocation, and I
can tail that in the usual way, same as you do.
A long time passed that I used nohup - I thought there was an
option to define the output file - but if I inspect the specs it
seems that redirection of stdin suffices to choose arbitrary
files.
(Did I misread the POSIX specs?)
Janis Papanagnou <janis_papanagnou+ng@hotmail.com>:
(Did I misread the POSIX specs?)
Other than that you read "stdin" where the POSIX specs write "stdout", no.
It has long seemed to me that nohup(1) was an old, hacky way of
doing what can be done more elegantly using setsid(1). Compare
the docs for yourself
<https://manpages.debian.org/1/nohup.1.en.html> vs <https://manpages.debian.org/1/setsid.1.en.html>, and tell me
why we still need nohup when we have setsid?
Lawrence D'Oliveiro <ldo@nz.invalid>:
It has long seemed to me that nohup(1) was an old, hacky way of
doing what can be done more elegantly using setsid(1). Compare
the docs for yourself
<https://manpages.debian.org/1/nohup.1.en.html> vs
<https://manpages.debian.org/1/setsid.1.en.html>, and tell me
why we still need nohup when we have setsid?
Because there is a real difference between both of them.
"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.
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.