Cfrgtkky

disown

• causes a shell not to send SIGHUP to its disowned job when the shell terminates, and




• removes the disowned job from the shell's job control.

Is the first the result of the second?
In other words, if a process started from a shell is removed from the shell's job control by any way, will the shell not send SIGHUP to the process when the shell terminates?

disown -h still keeps a process under a shell's job control. Does it mean that disown -h makes a process still receives SIGHUP sent from the shell, but sets up the action of SIGHUP by the process to be "ignore"? That sounds similar to nohup.

$ sleep 123 & disown -h

[1] 26103

$ jobs

[1]+  Running                 sleep 123 &

$ fg 1

sleep 123

$ ^Z

[1]+  Stopped                 sleep 125

$ bg 1

[1]+ sleep 123 &

$ exit



$ ps aux | grep sleep

t        26103  0.0  0.0  14584   824 ?        S    15:19   0:00 sleep 123

Do disown -h and nohup work effectively the same, if we disregard their difference in using a terminal?

Thanks.

nohup and disown -h are not exactly the same thing.

With disown, a process is removed from the list of jobs in the current interactive shell. Running jobs after starting a background process and running disown will not show that process as a job in the shell. A disowned job will not receive a HUP from the shell when it exits (but see note at end).

With disown -h, the job is not removed from the list of jobs, but the shell would not send a HUP signal to it if it exited (but see note at end).

The nohup utility ignores the HUP signal and starts the given utility. The utility inherits the signal mask from nohup and will therefore also ignore the HUP signal. When the shell terminates, the process remains as a child process of nohup (and nohup is re-parented to init).

The difference is that the process started with nohup ignores HUP regardless of who sends the signal. The disowned processes are just not sent a HUP signal by the shell, but may still be sent the signal from e.g. kill -s HUP <pid> and will not ignore this.

Note that HUP is only sent to the jobs of a shell if

• the shell is a login shell and the huponexit shell option is set, or


• the shell itself recieves a HUP signal.

Relevant bits from the bash manual (my emphasis):

SIGNALS

[...]

The shell exits by default upon receipt of a SIGHUP. Before exiting,
an interactive shell resends the SIGHUP to all jobs, running or
stopped. Stopped jobs are sent SIGCONT to ensure that they receive the
SIGHUP. To prevent the shell from sending the signal to a particular
job, it should be removed from the jobs table with the disown builtin
(see SHELL BUILTIN COMMANDS below) or marked to not receive SIGHUP
using disown -h.

If the huponexit shell option has been set with shopt, bash sends a
SIGHUP to all jobs when an interactive login shell exits.

disown [-ar] [-h] [jobspec ... | pid ... ]

Without options, remove each jobspec from the table of active
jobs. [...] If the -h option
is given, each jobspec is not removed from the table, but is
marked so that SIGHUP is not sent to the job if the shell
receives a SIGHUP. [...]

Related:

• Difference between nohup, disown and &

They are Different:

• disown removes the job from the active jobs table. Then continues on with current job. With -h the proccess is NOT sent SIGHUP. It is instead left to die with the shell that contains it, when it recieves a SIGHUP.



• 
  

  nohup ignores the HUP. Then anything that would have been passed to the terminal by the proccess closing instead goes to a file nohup.out.

  
  
  

  
  

  nohup is defined by POSIX while disown is not.