Re: Clarification on ksh(1) nohup mechanism

Folks,

On Sat 12/08/2017 18:36, Alessandro DE LAURENZIS wrote:
>Dear misc@ readers,
>
>I'm lost with the subject... From the man page I see that, differently
>from standard ksh, OpenBSD implementation by default do *not* send
>SIGHUP signals to child processes when a SIGHUP is received by the
>parent shell and that this mechanism can be changed through:
>
>set +o nohup
>
>So far, so good; now:
>
>[....................snip....................]
><open a new xterm>
>$ sleep 30 &
>[1] 46318
>$ pgrep -fl sleep
>46318 sleep 30
><close the terminal and open a new one>
>$ pgrep -fl sleep
>46318 sleep 30
>[....................snip....................]
>
>As expected, the sleep process is still there. But:
>
>[....................snip....................]
><open a new xterm>
>set +o nohup
>$ sleep 30 &
>[1] 83071
>$ pgrep -fl sleep
>83071 sleep 30
><close the terminal and open a new one>
>$ pgrep -fl sleep
>83071 sleep 30
>[....................snip....................]
>
>Even after having cleared the shell option, the process is not killed.
>
>Just in case, I also tried with:
>
>set -o nohup
>
>observing the same behavior.

I've discussed this topic off-list with anton@, and the conclusion of
his analysis is that the "set +o nohup" correct behaviour requires a ksh
login shell.

I confirm that, firing e.g. "ksh -l" from bash, child processes
correctly receive a SIGHUP at ksh's closing; instead, firing just "ksh"
shows the unexpected behaviour I described above.

Now, I doubt that signal handlers should be influenced by the
login/non-login assumption, or at least that's not documented... I hope
one of the developers will have a look.

All the best

--
Alessandro DE LAURENZIS
[mailto:just22@atlantide.t28.net]
LinkedIn: http://it.linkedin.com/in/delaurenzis