Hi Chris,
Chris Marusich <[email protected]> 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’.
