I'm trying chutney to measure my CPU, but it does not appear to work:
chutney/tools/test-network.sh --flavour basic-min --data-bytes 104857600 test-network.sh: using CHUTNEY_DNS_CONF '/dev/null' test-network.sh: no $TOR_DIR, chutney will use $PATH for tor binaries test-network.sh: $CHUTNEY_PATH not valid, using this script's location Using Python 2.7.14 Sending SIGINT to nodes Waiting for nodes to finish. Removing stale lock file for test000a ... Removing stale lock file for test001a ... bootstrap-network.sh: bootstrapping network: basic-min Using Python 2.7.14 NOTE: creating '/home/user/chutney/tools/../net/nodes.1517749361', linking to '/home/user/chutney/tools/../net/nodes' Creating identity key /home/user/chutney/net/nodes/000a/keys/authority_identity_key for test000a with tor-gencert --create-identity-key --passphrase-fd 0 -i /home/user/chutney/net/nodes/000a/keys/authority_identity_key -s /home/user/chutney/net/nodes/000a/keys/authority_signing_key -c /home/user/chutney/net/nodes/000a/keys/authority_certificate -m 12 -a 127.0.0.1:7000 Creating identity key /home/user/chutney/net/nodes/001a/keys/authority_identity_key for test001a with tor-gencert --create-identity-key --passphrase-fd 0 -i /home/user/chutney/net/nodes/001a/keys/authority_identity_key -s /home/user/chutney/net/nodes/001a/keys/authority_signing_key -c /home/user/chutney/net/nodes/001a/keys/authority_certificate -m 12 -a 127.0.0.1:7001 Using Python 2.7.14 Starting nodes
Using Python 2.7.14 test000a is running with PID 1001 test001a is running with PID 1004 test002r is running with PID 1007 test003c is running with PID 1010 4/4 nodes are running Waiting 20 seconds for a consensus containing relays to be generated... Running 1 verify rounds... Using Python 2.7.14 Verifying data transmission: (retrying for up to 60 seconds) Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Connecting: Exit to 127.0.0.1:4747 via client localhost:9003 Transmitting Data:
Transmission: Failure Set CHUTNEY_DEBUG to diagnose. Completed 1 of 1 verify rounds. Using Python 2.7.14 Sending SIGINT to nodes Waiting for nodes to finish. Removing stale lock file for test000a ... Removing stale lock file for test001a ... Removing stale lock file for test002r ... Removing stale lock file for test003c ... Summary: nodes Detail: chutney/tools/warnings.sh /home/user/chutney/tools/../net/nodes.1517749361 Warning: OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1010007f: OpenSSL 1.1.0g 2 Nov 2017; running with 1010007f: OpenSSL 1.1.0g-fips 2 Nov 2017). Number: 4
------------------------
open tor listener (after starting chutney) tcp 0 0 0.0.0.0:7000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:7001 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:7002 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8000 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8002 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5000 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5001 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:5002 0.0.0.0:* LISTEN
there is no tor on tcp port 9003, should there be one?
grep 9003 chutney/net/nodes/*/torrc chutney/net/nodes/003c/torrc:SocksPort 9003
manually starting that torrc file (after setting RunAsDaemon to 0) gives:
tor -f /home/user/chutney/net/nodes/003c/torrc --Log "info stdout"
(Sandbox) Caught a bad syscall attempt (syscall kill) tor(+0x1853fa)[0x6141342b23fa] /lib64/libc.so.6(kill+0x7)[0x75008527ace7] /lib64/libc.so.6(kill+0x7)[0x75008527ace7] tor(+0x1c3bab)[0x6141342f0bab] /lib64/libevent-2.0.so.5(event_base_loop+0x7a9)[0x7500863853f9] tor(do_main_loop+0x29d)[0x61413417b78d] tor(tor_main+0xe25)[0x61413417e5a5] tor(main+0x19)[0x614134177009] /lib64/libc.so.6(__libc_start_main+0xea)[0x75008526488a] tor(_start+0x2a)[0x61413417705a]
Tor version 0.3.1.9 upgrading to 0.3.2.9 solves the issue. https://trac.torproject.org/projects/tor/ticket/24198
Hi Nick,
On 5 Feb 2018, at 00:36, tor7 tor7@mailbox.org wrote:
(Sandbox) Caught a bad syscall attempt (syscall kill) tor(+0x1853fa)[0x6141342b23fa] /lib64/libc.so.6(kill+0x7)[0x75008527ace7] /lib64/libc.so.6(kill+0x7)[0x75008527ace7] tor(+0x1c3bab)[0x6141342f0bab] /lib64/libevent-2.0.so.5(event_base_loop+0x7a9)[0x7500863853f9] tor(do_main_loop+0x29d)[0x61413417b78d] tor(tor_main+0xe25)[0x61413417e5a5] tor(main+0x19)[0x614134177009] /lib64/libc.so.6(__libc_start_main+0xea)[0x75008526488a] tor(_start+0x2a)[0x61413417705a]
Tor version 0.3.1.9 upgrading to 0.3.2.9 solves the issue.
Can we backport the following sandbox fixes to 0.3.1 and 0.2.9 before the next release:
https://trac.torproject.org/projects/tor/ticket/24198 https://trac.torproject.org/projects/tor/ticket/24315
(There might be others, I haven't checked.)
T
tor-relays@lists.torproject.org