Re: Adding a TOR system test - confusing results

[Ludovic Courtès]

Hi Chris,

Chris Marusich <address@hidden> skribis:

> To begin, let's apply the first patch ("Add system tests for the TOR
> service.").  Then run the test:
>
> $ make -j1 check-system TESTS=tor
> [...]
> # of expected passes      1
> @ build-succeeded /gnu/store/zdh97qnh4b69yr23yp5js16hw9lvjhzm-tor-test.drv -
> TOTAL: 1
> PASS: /gnu/store/c3f0y7jbqi1qw8s63p3jbp5mrwl1bxnc-tor-test
>
>
> It passed!  Great!  Now, let's make sure it also detects failures
> correctly: Let's break TOR by applying the second patch ("For testing
> purposes, break the TOR service.").  Then run it again:
>
> $ make -j1 check-system TESTS=tor
> [...]
> This is the GNU system.  Welcome.
> komputilo login: exec of 
> "/gnu/store/5jhlsv29n6kx76na1kkgfarznrl5kjjg-tor-0.3.3.9DOES-NOT-EXIST" 
> failed: No such file or directory
> QEMU runs as PID 4
> connected to QEMU's monitor
> read QEMU monitor prompt
> connected to guest REPL
> %%%% Starting test tor  (Writing full log to "tor.log")
> marionette is ready
> # of expected passes      1
> @ build-succeeded /gnu/store/z8q9y8zivsipaq9fdj7yhhcvqgfq8ryl-tor-test.drv -

The problem has to do with ‘make-forkexec-constructor/container’: it
creates a process (with ‘run-container’) that exec’s the program, and
then returns immediately.  Thus we know that a process was created, but
we don’t know that soon after that it exited because of a failed ‘exec’
call.

If you run it in a VM, you’ll notice that shepherd tries to respawn it
several times in a row and eventually disables the service.

The test above is unreliable because during this fail/respawn cycle, the
service keeps going up and down.

The solution here would be to use a PID file for the Tor service.  That
would (1) allow us to properly detect failure to run Tor, and (2)
provide better synchronization with Tor startup.

HTH!

Ludo’.