Implicit killing of subprocesses

Implicit killing of subprocesses

[René Neumann]

Hi,

I have a question regarding if and when subprocesses are killed when
exiting a shell script.

My case: I want to pipe the output of a longrunning process (here:
dbus-monitor) through some evaluation. As it does not read from stdin, I
can't simply close it by sending EOF.

When I use

coproc dbus-monitor
while read -p line; do ... done

the dbus-monitor process lurks around after the script finishes
(breaking or returning from the loop).

When I use

dbus-monitor | while read -p line; do ... done

it does not (i.e. it gets killed).

My questions now are:

- Can I build on the process being killed when exiting the loop (in the
second case)? Or does it only work in some cases?

- Is it intentional that coprocs don't get killed and I have to make it
by hand? (Which is hard if you have "coproc dbus-monitor | grep ...", as
$! only holds the grep).

Thanks and regards,
René

Re: Implicit killing of subprocesses

[René Neumann]

Am 28.08.2013 14:54, schrieb René Neumann:

> When I use
> 
> dbus-monitor | while read -p line; do ... done

without the -p here obviously :)

- René

Re: Implicit killing of subprocesses

[Peter Stephenson]

On Wed, 28 Aug 2013 14:54:32 +0200
René Neumann <lists@necoro.eu> wrote:
> When I use
> 
> coproc dbus-monitor
> while read -p line; do ... done
> 
> the dbus-monitor process lurks around after the script finishes
> (breaking or returning from the loop).

Hmm... assuming this is interactive, you should see enough job control
messages to alert you to what's going on.  With no options set, it would
be something like:

% coproc cat
[1] 4757
% exit
zsh: you have running jobs.
% exit
zsh: warning: 1 jobs SIGHUPe

indicating the coprocess has been sent SIGHUP.  If you had the NOHUP
option set, it would still warn you but it wouldn't send SIGHUP.

Not sure what happens non-interactively, coproc is really there for use
with job control.

pws

Re: Implicit killing of subprocesses

[René Neumann]

Am 28.08.2013 15:26, schrieb Peter Stephenson:
> On Wed, 28 Aug 2013 14:54:32 +0200
> René Neumann <lists@necoro.eu> wrote:
>> When I use
>>
>> coproc dbus-monitor
>> while read -p line; do ... done
>>
>> the dbus-monitor process lurks around after the script finishes
>> (breaking or returning from the loop).
> 
> Hmm... assuming this is interactive, you should see enough job control
> messages to alert you to what's going on.  With no options set, it would
> be something like:

It's non-interactive (a script).

> Not sure what happens non-interactively, coproc is really there for use
> with job control.

Ah darn. Using coprocs in scripts comes in handy when you want sth like:

coproc long_running

while read -p; ...

# something else

while read -p; ...


That's why, I thought it was meant for non-interactive cases.

- René

Re: Implicit killing of subprocesses

[Peter Stephenson]

On Wed, 28 Aug 2013 15:38:30 +0200
René Neumann <lists@necoro.eu> wrote:
> It's non-interactive (a script).
> 
> > Not sure what happens non-interactively, coproc is really there for use
> > with job control.
> 
> Ah darn. Using coprocs in scripts comes in handy when you want sth like:

I think you're OK, it's just you don't have job control (and all the
paraphernalia of controlling terminals, sessions, and the stuff zsh-workers
will know I don't really understand).

In this case, the NOHUP option is irrelevant --- because you don't have
job control (it's determined by the MONITOR option which is unset in
non-interactive shells), the shell doesn't send SIGHUP to processes on
exiting (without job control it doesn't have much idea of which
processes would need it).  So I think you get the effect you want.

pws

Re: Implicit killing of subprocesses

[Bart Schaefer]

On Aug 28,  2:47pm, Peter Stephenson wrote:
}
} In this case, the NOHUP option is irrelevant --- because you don't have
} job control (it's determined by the MONITOR option which is unset in
} non-interactive shells), the shell doesn't send SIGHUP to processes on
} exiting (without job control it doesn't have much idea of which
} processes would need it).  So I think you get the effect you want.

I think the effect Rene wants is that the coproc job DOES get killed when
the script exits?  Which won't happen with MONITOR turned off.

A coproc is not very different than a backgroup job started with "... &" 
except for where its standard input and output are connected.

However, you can "setopt monitor" in the script.  If you do this before
starting the coproc, zsh SIGHUPs the job before exiting.  You get the
usual warnings:

coprocscript:7: you have running jobs.
coprocscript:7: warning: 1 jobs SIGHUPed

If the setopt comes after the coproc, the first warning is printed, but
the SIGUP is not sent.

If the job started with coproc can be relied upon to exit when it gets
EOF on its standard input, then instead of setopt monitor you can end it
explicitly with:

TRAPEXIT() { coproc exit }

The "coproc exit" is not magic, it's just an idiom for closing all the
existing coproc descriptors in the parent shell by starting a new no-op
coproc in place of whichever one is already running.  It is best if the
TRAPEXIT is not created until after the coproc job is started.

Re: Implicit killing of subprocesses

[Peter Stephenson]

On Wed, 28 Aug 2013 08:59:52 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Aug 28,  2:47pm, Peter Stephenson wrote:
> }
> } In this case, the NOHUP option is irrelevant --- because you don't have
> } job control (it's determined by the MONITOR option which is unset in
> } non-interactive shells), the shell doesn't send SIGHUP to processes on
> } exiting (without job control it doesn't have much idea of which
> } processes would need it).  So I think you get the effect you want.
> 
> I think the effect Rene wants is that the coproc job DOES get killed when
> the script exits?

Oh, right.


coproc cat
coproc_pid=$!

TRAPEXIT() { kill $coproc_pid }


pws

Re: Implicit killing of subprocesses

[René Neumann]

Am 28.08.2013 18:11, schrieb Peter Stephenson:
> On Wed, 28 Aug 2013 08:59:52 -0700
> Bart Schaefer <schaefer@brasslantern.com> wrote:
>> On Aug 28,  2:47pm, Peter Stephenson wrote:
>> }
>> } In this case, the NOHUP option is irrelevant --- because you don't have
>> } job control (it's determined by the MONITOR option which is unset in
>> } non-interactive shells), the shell doesn't send SIGHUP to processes on
>> } exiting (without job control it doesn't have much idea of which
>> } processes would need it).  So I think you get the effect you want.
>>
>> I think the effect Rene wants is that the coproc job DOES get killed when
>> the script exits?
> 
> Oh, right.
> 
> 
> coproc cat
> coproc_pid=$!
> 
> TRAPEXIT() { kill $coproc_pid }

Gets problematic though with

coproc cat | grep foo

as $! now only holds the PID of grep.

- René

Re: Implicit killing of subprocesses

[Bart Schaefer]

On Aug 28,  6:27pm, René Neumann wrote:
>
> coproc cat | grep foo
> 
> $! now only holds the PID of grep.

coproc { cat | grep foo }