Skip to main content
Have another item of further reading.
Source Link
JdeBP
  • 71.9k
  • 13
  • 175
  • 378

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.

Further reading

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.

Further reading

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.

Further reading

Have some further reading.
Source Link
JdeBP
  • 71.9k
  • 13
  • 175
  • 378

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.

Further reading

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.

Further reading

Source Link
JdeBP
  • 71.9k
  • 13
  • 175
  • 378

Why doesn't the process stop when I exit the shell?

Probably because you told the shell to disown it. Or you might not be using an interactive job control shell as your session leader process.

The combined session+process groups model that the world settled upon in the 1980s works like this: There is a session leader process. That is what gets the hangup signal from the terminal line discipline when the terminal is hung up. It is expected to amplify that signal, itself sending the signal to all of the "jobs" that it has spawned. Interactive job control shells will do this; most other programs do not expect to have the responsibilities of session leaders, and will not.

Using nohup makes the processes in those "jobs" ignore the hangup signal when the session leader sends it to them. Using disown makes the session leader shell forget about a job, so that it never sends a hangup signal to it in the first place.

Can I safely assume my processes won't end if I don't use nohup?

No. If they have not been disowned, then they will be sent a hangup signal by a session leader interactive job control shell process.

Furthermore: The systemd people have tried to implement a user-space mechanism equivalent to kernel sessions, but they have made a bit of a pig's ear of it, which introduces further complications on (some) systemd operating systems. At systemd session hangup instead of sending SIGHUP to just the session leader as the kernel's line discipline does, they erroneously send SIGTERM to all processes, erroneously signifying shutdown rather than hangup.

SIGTERM to all processes is of course what happens, in the standard session+process groups model, at system shutdown; and that kills all processes, including disowned ones and ones that ignore the hangup signal. It will kill your processes that have been neither disowned nor nohuped, as well of course.