Funding channel causes crash due to "UNIQUE constraint failed: peers.node_id" #1029
Comments
|
Indeed, sorry for missing that one. The issue seems to have been resolved for @Sjors after a dev-rescan-outputs. I can still reproduce it though. My node was caught up by now, and I ran this: Node crashed with same error. |
|
Hmm, what state does the db say it's in? |
|
@rustyrussell |
|
@rustyrussell, still the same: There is an entry for the peer but no channel for it: |
|
I also have this error, running commit e48a97f This occurred while the node was unattended, so was not due to any direct action by me |
|
|
Same issue here, it happens reproducibly between two of my own nodes, which used to have a channel in the past. This channel was auto-closed due to unknown (to me) reasons. When I try to fundchannel a new channel from the one to the other node, on the connected-to node I get the error: Same result as those above when trying with |
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this issue
Feb 22, 2018
Fixes: ElementsProject#1029 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
added a commit
to rustyrussell/lightning
that referenced
this issue
Feb 22, 2018
Fixes: ElementsProject#1029 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
Thanks for all the reports.
We now eliminate peers from db when no more channels. But we didn't
always, so we can have old ones.
Fix incoming...
"Wladimir J. van der Laan" <notifications@github.com> writes:
… Same issue here, it happens reproducibly between two of my own nodes, which used to have a channel in the past. This channel was auto-closed due to unknown (to me) reasons. When I try to fundchannel a new channel from the one to the other node, on the connected-to node I get the error:
```
wallet_channel_insert: UNIQUE constraint failed: peers.node_id
Program received signal SIGABRT, Aborted.
__GI_raise ***@***.***=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise ***@***.***=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f2cc7c7f3fa in __GI_abort () at abort.c:89
#2 0x0000556ecf2104ca in fatal (fmt=0x556ecf2aeea5 "%s: %s") at lightningd/log.c:592
#3 0x0000556ecf250fe1 in db_exec_prepared_ (caller=0x556ecf2b1ba0 <__func__.9071> "wallet_channel_insert", db=0x556ecf5a89c0, stmt=0x556ed0b292d8) at wallet/db.c:219
#4 0x0000556ecf2566ef in wallet_channel_insert (w=0x556ecf5a31a0, chan=0x556ed0b27770) at wallet/wallet.c:897
#5 0x0000556ecf21e298 in wallet_commit_channel (ld=0x556ecf5a2030, uc=0x556ed0b2fd80, remote_commit=0x556ed0b31100, remote_commit_sig=0x7fff34014870, funding_txid=0x7fff34014850, funding_outnum=1,
funding_satoshi=129845, push_msat=0, channel_flags=1 '\001', channel_info=0x7fff34014940, feerate=293) at lightningd/peer_control.c:2239
#6 0x0000556ecf21ee11 in opening_fundee_finished (openingd=0x556ed0b302f0, reply=0x556ed0b27260 <incomplete sequence \327>, fds=0x556ed0b306e0, uc=0x556ed0b2fd80) at lightningd/peer_control.c:2445
#7 0x0000556ecf225d10 in sd_msg_reply (conn=0x556ed0b305e0, sd=0x556ed0b302f0, sr=0x556ed0b30b50) at lightningd/subd.c:307
#8 0x0000556ecf2262cb in sd_msg_read (conn=0x556ed0b305e0, sd=0x556ed0b302f0) at lightningd/subd.c:435
#9 0x0000556ecf225e11 in read_fds (conn=0x556ed0b305e0, sd=0x556ed0b302f0) at lightningd/subd.c:328
#10 0x0000556ecf2615c5 in next_plan (conn=0x556ed0b305e0, plan=0x556ed0b30610) at ccan/ccan/io/io.c:59
#11 0x0000556ecf2620c2 in do_plan (conn=0x556ed0b305e0, plan=0x556ed0b30610, idle_on_epipe=false) at ccan/ccan/io/io.c:387
#12 0x0000556ecf262100 in io_ready (conn=0x556ed0b305e0, pollflags=1) at ccan/ccan/io/io.c:397
#13 0x0000556ecf263a4a in io_loop (timers=0x556ecf5a2120, expired=0x7fff34014d78) at ccan/ccan/io/poll.c:310
#14 0x0000556ecf20e71a in main (argc=9, argv=0x7fff34014ea8) at lightningd/lightningd.c:373
```
Same result when trying with `sqlite3`: the peer is in the database, no channels.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1029 (comment)
|
cdecker
pushed a commit
that referenced
this issue
Feb 22, 2018
Fixes: #1029 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
|
Thanks, I can confirm that this issue is fixed for me! |
|
I'm having the same issue with v0.6.2 - peers table has a record which no channel on channels table is referencing. When said peer is trying to Here are the logs from the channel closing event few weeks ago: While #1066 removes such channel-less peers during upgrade, until it does, a peer in that state will crash a node whenever it tries opening a channel. Wasn't sure if to comment here or open new, let me know if a new issue is better. |
|
@yoss1x maybe better to make a new issue, referencing this one. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I connected to a node and opened a channel:
Lightningd crashed:
By the time of the crash, my node was fully caught up. After the restart, it's now catching up again:
I might have been connected to this node in the past. I happen to have a copy of the sqllite DB from before the crash.
So despite listpeers not listing the node, it's still in the peers table. There is no channel referencing it though:
sqlite> select id, state from channels where hex(peer_id) like "0333%";I can reproduce this, so let me know if you need more info.
The text was updated successfully, but these errors were encountered: