[Toybox] [PATCH] killall.test, pidof.test: deflake.

[enh]

On Sat, Sep 28, 2019 at 9:38 AM Rob Landley <rob at landley.net> wrote:
>
> On 9/19/19 9:45 AM, enh wrote:
> > On Thu, Sep 19, 2019 at 7:37 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 9/16/19 3:17 PM, enh via Toybox wrote:
> >>> Rarely (but these tests now get run often), it seems like we catch the
> >>> shell between its fork and exec of sleep, which counts as false
> >>> positives for killall/pidof. Since we don't actually need to sleep, just
> >>> have the shell script spin instead.
> >>
> >> What's the failure here? The fork but not yet exec means we think the shell has
> >> done a (subshell) or backgrounded& something, so we killed two instances of the
> >> test. Ok. This is bad how? Isn't killall supposed to kill all? (What test
> >> actually fails?)
> >
> > the test is checking the list of pids (so we can tell it's actually
> > doing anything), so there's an unexpected extra entry.
>
> Ok, let's see...
>
> wait and wait -n both exit immediately if it knows you have no child processes,
> wait 1 says pid 1 is not a child of this shell....
>
> "suspend" requires SIGCONT to continue and other signals are blocked, plus the
> Defective Annoying SHell in debian hasn't got it and you're doing $(which
> randomshell).
>
> Hmmm, can't symlink it straight to sleep because it's testing -x to see through
> script, so I have to have a test _script_.
>
> I don't want a failed test to leave a cpu-eating loop running because I didn't
> notice and it drained my battery a couple times...

i've actually found that more _useful_ than problematic... i never
find those kinds of test bugs on my desktop because it has too many
cores for me to ever notice. but my laptop helpfully gets warm, and we
can fix the issue.

that said, i have been thinking that maybe we should use setsid(1) or
something to just automate cleanup, like we clean up temporary
directories unless asked to keep them.

> Hmmm... maybe a max count in the loop? Except how big the count should be varies
> WILDLY over various hardware and it could theoretically get fast enough to cause
> failures. It's a pity there isn't a $UNIXTIME builtin...
>
> Aha!
>
> echo -e "#!$(which sh)\nread i < /proc/self/fd/1" > pidof.test
>
> That hangs. And now I want the "process killed" lines to go away, but I need the
> PID... Ugh, seriously? This is hanging?
>
>   pid=$(./pidof.test & echo $!)
>
> That is an ampersand. It is BACKGROUNDING pidof.test. It works as (thingy&) and
> then thingy doesn't show up in job control because the subshell exited (the
> classic double fork and exec) except I need the PID of the child process, and
> that syntax should do it! Ugh, let's see, redirecting the $! to >&2 does give me
> output so it's RUNNING, it's just $() is refusing to exit until background jobs
> exit (WHO ASKED YOU, is this a bash behavior I need to match in toysh?
> Probably.) and adding ; disown $! wasn't enough (although $! probably blanks
> after reading once) so how about...
>
> Ok, I've made it as far as:
>
>   pid="$( (./pidof.test & echo $!)& disown $! )"
>
> And it's still hanging, I'm breaking for lunch.
>
> Rob