On August 27, 2017 6:28:12 PM GMT+02:00, Alessandro DE LAURENZIS <jus...@atlantide.t28.net> wrote: >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.
From ksh(1): "Note that for non-interactive shells, the trap handler cannot be changed for signals that were ignored when the shell started." I bet this is what bites you. /Alexander > >All the best
