Frozen command substitution

Frozen command substitution

[Dominik Vogt]

I have two long running scripts that do complex interaction with
the web browser, say "foo" which calls the subordinate script
"bar".  The browser crashes once in a while and is restarted
automatically by some other script.  Sometimes when this happens,
foo freezes in a call of bar and won't wake up anymore when bar
terminates:

-- foo --
while true; do
	some-func
	test some-condition && break
done

some-func () {
	while true; do
		R="$(bar ssome arguments)"  <------- hangs in this line
		test some condition && return 0
	done
}
-- foo --

-- bar --
# some long-running loop
# ...

return 0
-- bar --

Ciao

Dominik ^_^  ^_^

--

So, foo calls bar in a loop.  While bar is running, the browser is
restarted.  bar detects this, finishes and exits with the "return
0".  However, foo does not continue with the line after the
command substitution.  A "ctrl-z" foollowed by "fg" does not help.
Sending it SIGUSR1 (which has a trap installed) wakes it up again.
In the process list:

  $ pstree -a
  ...
  <terminal>-+-zsh-+-foo
                   |-tee
                   +-zsh

(The whole stuff is calles with
"while true; do foo 2>&1 | tee foo.out; done".)  /proc/<pid>/status says:

  $ cat /proc/<pid>/status
  ...
  State:  S (sleeping)
  Tgid:   13030
  Ngid:   0
  Pid:    13030
  PPid:   24927
  ...

foo has a trap for "HUP" installed, and that's being called when
when I type "killall -HUP foo", so the shell is not dead.  "ps"
lists the processes' status as "S+".

Dominik Vogt

Re: Frozen command substitution

[Dominik Vogt]

On Sat, Feb 11, 2023 at 10:41:07AM +0100, Dominik Vogt wrote:
> I have two long running scripts that do complex interaction with
> the web browser, say "foo" which calls the subordinate script
> "bar".  The browser crashes once in a while and is restarted
> automatically by some other script.  Sometimes when this happens,
> foo freezes in a call of bar and won't wake up anymore when bar
> terminates:

> 		R="$(bar some arguments)"  <------- hangs in this line

Apparingly this does not happen if the line is rewritten to

> 		bar some arguments | read R

(bar produces exactly one line of output.)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt

Re: Frozen command substitution

[Bart Schaefer]

On Sat, Feb 11, 2023 at 9:03 AM Dominik Vogt <dominik.vogt@gmx.de> wrote:
>
> On Sat, Feb 11, 2023 at 10:41:07AM +0100, Dominik Vogt wrote:
> > foo freezes in a call of bar and won't wake up anymore when bar
> > terminates:
>
> >               R="$(bar some arguments)"  <------- hangs in this line
>
> Apparingly this does not happen if the line is rewritten to
>
> >               bar some arguments | read R

Look for a file or pipe that's been opened in foo to which the
subshell for bar might still have a descriptor (obviously other than
the fd to return bar's output).

Re: Frozen command substitution

[Dominik Vogt]

On Sat, Feb 11, 2023 at 09:36:01AM -0800, Bart Schaefer wrote:
> On Sat, Feb 11, 2023 at 9:03 AM Dominik Vogt <dominik.vogt@gmx.de> wrote:
> >
> > On Sat, Feb 11, 2023 at 10:41:07AM +0100, Dominik Vogt wrote:
> > > foo freezes in a call of bar and won't wake up anymore when bar
> > > terminates:
> >
> > >               R="$(bar some arguments)"  <------- hangs in this line
> >
> > Apparingly this does not happen if the line is rewritten to
> >
> > >               bar some arguments | read R
>
> Look for a file or pipe that's been opened in foo to which the
> subshell for bar might still have a descriptor (obviously other than
> the fd to return bar's output).

Hm, either script may restart the browser if the browser hangs.
After killing it I use this to restart it:

  start-browser () {
          ( set -m; "$BROWSER" <options> <url> &! )
  }

Does this have some side effect that I'm not aware of?  The idea
was to decouple the browser from the script so that it won't be
killed when the script ends.

(This is all a bit more complicated because the browser runs
inside a sandbox (firjail) and killing the browser actually means
terminating the sandbox.  But I think that's not part of the
problem.)

Ciao

Dominik ^_^  ^_^

--

Dominik Vogt