guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding a TOR system test - confusing results


From: Chris Marusich
Subject: Re: Adding a TOR system test - confusing results
Date: Mon, 23 Jul 2018 20:11:51 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi Ludo,

address@hidden (Ludovic Courtès) writes:

> 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.

That makes sense.  TOR supports a PID file, so I'll give that a try.

In the meantime, there is another similar mystery I could not solve.
Consider the attached patch, which applies cleanly on top of the first
patch in my previous email.  This is what it does when I run it:

--8<---------------cut here---------------start------------->8---
$ make -j 1 check-system TESTS=tor
[...]
This is the GNU system.  Welcome.
komputilo login: Jul 24 03:07:46.688 [notice] Tor 0.3.3.9 
(git-45028085ea188baf) running on Linux with L.
Jul 24 03:07:46.692 [notice] Tor can't help you if you use it wrong! Learn how 
to be safe at https://wwwg
Jul 24 03:07:46.702 [notice] Read configuration file 
"/gnu/store/g4h37si0fjqijrqp6smn6jq23bqj1051-torrc".
Jul 24 03:07:46.731 [notice] Scheduler type KIST has been enabled.
Jul 24 03:07:46.733 [notice] Opening Socks listener on 127.0.0.1:9050
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/g35kgsr3298k2s15nn3f8qpcxbdxrvrl-tor-test.drv -
TOTAL: 1
PASS: /gnu/store/ghkrf4cx4mkmzjyx1m8hdg5hbk6zjzb2-tor-test
--8<---------------cut here---------------end--------------->8---

Why does it pass?  The (sleep 999999) form appears to be totally
ignored, and I don't understand why.  It's concerning to me that I can't
understand how the code is being executed.  I expected the test to hang.

-- 
Chris

Attachment: 0001-Sleep-for-about-278-hours-during-the-TOR-test.patch
Description: Text Data

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]