[Toybox] [PATCH] pidof.test: block on sleep rather than read.

[Rob Landley]

On 1/22/20 11:02 PM, enh via Toybox wrote:
> The commit that added the read mentioned the killall tests, but they use
> sleep. Blocking on a read of stdout is failing in some of the Android
> test infrastructure where it seems to end up connected to a socket.
> 
>   ./pidof-12488.test[2]: can't open /proc/self/fd/1: No such device or address

Sleep was spawning a child process, which meant it would fork() another instance
of the same process before calling exec(), and thus kill and such were reporting
multiple processes matched if they happened at exactly the wrong time, which was
intermittently breaking your testing.

That's why I changed it. You're reintroducing the old problem. I don't see how
we can fork() without that window. (Now maybe we can have a LONG pause to let
the fork flush through, but that's a question of the system you're running it on?)

And we can't do the "ln -s $(which sleep) spleep" trick because we're
specifically checking the "/bin/bash script.sh matches script.sh" part of the
plumbing here, so it has to have an interpreter...

Oh: Maybe we could #!/bin/sleep and then call the script "10". :)

$ echo -e '#!'"$(which sleep)\nblah\n" > 10; chmod +x 10; ./10
/bin/sleep: invalid time interval ‘./10’
Try '/bin/sleep --help' for more information.

Hmmm...

$ echo -e '#!'"$(which sleep)\nblah\n" > 10; chmod +x 10; PATH=":$PATH" 10
/bin/sleep: invalid time interval ‘./10’
Try '/bin/sleep --help' for more information.

Seriously? That's really how you're gonna play this bash?

Sigh, skip all the previous ratholes I've been down ("wait" can't take an
arbitrary PID only an existing child process, and wait -n with no children
returns immediately...)

Sadly, when debian's "flock" says it can take a filename in its man page:

  $ cat blah
  #!/usr/bin/flock
  true
  $ flock blah -c ./blah
  flock: bad file descriptor: './blah'


it lies. (And toybox never implemented the non-fd stuff anyway; no idea why it
implemented the _fd_ stuff but clearly somebody wanted this...)

Sigh, I can "yes > /dev/null" but that's a CPU eating loop if it doesn't work
and I hate leaving those around as debris.)

How about:

  tty -s && skip_test
  blah < /dev/tty

Which is a sad aribtrary limitation I don't like but would at least probably
skip the test entirely on your irreproducible test environment?

I can create a dedicated C program to act as the test?

(Sigh, why couldn't we trust a read from stdin to block again? Just running
"cat" would give us something to kill that doesn't eat CPU if we don't. I think
one of your test containers was broken with that, but I forget?)

Rob