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:[email protected]]
LinkedIn: http://it.linkedin.com/in/delaurenzis
