Clarification on ksh(1) nohup mechanism

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Clarification on ksh(1) nohup mechanism

Alessandro DE LAURENZIS-3
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.

Could you please give me some hints?

All the best

-- Alessandro DE LAURENZIS
[mailto:[hidden email]]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Reply | Threaded
Open this post in threaded view
|

Re: Clarification on ksh(1) nohup mechanism

Alessandro DE LAURENZIS-3
Anyone?

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.
>
>Could you please give me some hints?
>
>All the best
>
>-- Alessandro DE LAURENZIS
>[mailto:[hidden email]]
>LinkedIn: http://it.linkedin.com/in/delaurenzis
>

--
Alessandro DE LAURENZIS
[mailto:[hidden email]]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Reply | Threaded
Open this post in threaded view
|

Re: Clarification on ksh(1) nohup mechanism

Alessandro DE LAURENZIS-3
In reply to this post by Alessandro DE LAURENZIS-3
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:[hidden email]]
LinkedIn: http://it.linkedin.com/in/delaurenzis

Reply | Threaded
Open this post in threaded view
|

Re: Clarification on ksh(1) nohup mechanism

Alexander Hall


On August 27, 2017 6:28:12 PM GMT+02:00, Alessandro DE LAURENZIS <[hidden email]> 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