This fails on the old dev-restart tests, so we need to only enable it
for the new tests:
rusty@rusty-XPS-13-9360:~/devel/cvs/lightning (guilt/ping-pong)$ daemon/test/test-basic --restart --verbose
...
{ }
RESTARTING
dev-restart failed!
valgrind: mmap(0x38000000, 2265088) failed in UME with error 22 (Invalid argument).
valgrind: this can be caused by executables with very large text, data or bss segments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use a different 'struct peer' in the new daemons, so make sure
the structure isn't assumed in any shared files.
This is a temporary shim.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Or for blackbox tests --gdb1=<subdaemon> / --gdb2=<subdaemon>.
This makes the subdaemon wait as soon as it's execed, so we can attach
the debugger.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The API formalizes how daemons should report their statuses back to
the main lightningd. It's a simple write API, which includes tracing
support (currently it always sends traces, later it could send iff
there's a failure, for example).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When we support the Milan protocol, we'll use a default port. But
for now, don't listen at all unless a port is specified.
Fixes: #54
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added .travis.yml to get travis-ci to build and run tests for us.
In addition this fixes a flaky test due to the fact that when lightning2
connects to lightning3 and we tell lightning3 to restart, then
lightning2 will back-off its reconnection attempts, potentially causing
a timeout to trigger during tests. This was triggered by travis-ci
relatively consistently since the restart would take quite some
time. Now simply restarting them in reverse order and a small timeout
seems to fix this consistently.
This significantly reduces re-testing of the same paths, and simplifies
the addition of new tests.
make check -j12 times:
Before: 9m24.973s
After: 7m52.005s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's possible that we won't have sent the anchor, but state is
committed in db. And our current philosophy is that we retransmit all
the txs dumbly, all the time.
Our --restart --timeout-anchor test trigger this case, too, so
re-enable that now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Importantly, they're now entirely block driven. We don't use
dev-setmocktime at all any more.
This also fixes a bug if we run the test twice against the same
bitcoind; we need to extract the time from the block header rather
than assuming bitcoind is on the current time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means running 3 bitcoinds, which is slow enough to start on my laptop
that I need to increase the startup wait for 30 to 60 seconds, and similarly
the test.sh check loop.
Before: real 13m42.868s
After: real 8m19.563s (make -j3)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Waiting until lightningd is up is too long: do a --version test in setup,
and then check that all reported versions match later on.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We've seen intermittant failures on testnet, so disable sending feechanges
for now: we're completely changing it for 0.6 anyway, due to Milan Spec.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This gives much better errors, and allows us to return the peer id.
Closes: #37
Reported-by: Glenn Willen
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, remove fee ranges on testnet (too unreliable) and accept
a single confirm.
(Note that an earlier version of this had a bug when there was no
config file, this version includes the fix).
Closes: #40
Reported-by: Glenn Willen
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Firstly, we need to update the staging fee amount when we queue a change.
Secondly we need to remove completed fee updates, otherwise we hit a
database constraint that peer & state are unique.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Three days of on and off debugging, before I realized my server was talking
to a non-testnet bitcoind. There was a bitcoind on that machine running
on testnet, but it uses the same dir and config, so the --bitcoin-datadir
option couldn't help.
This is more certain: specify whether we're testnet on every single query.
Now we can skip the attempt to parse bitcoin.conf, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
NO_VALGRIND= daemon/test/test.sh --normal --restart
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
lightning-cli: Connecting to 'lightning-rpc': Connection refused
This is expected: it happens when node3 is restarting. Redirect
errors to /dev/null.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
Christian Decker