The Lightning Network FAQ - page 13.

darkv0rt3x

hero member

Activity: 1260

Merit: 675

I rather die on my feet than to live on my knees

Quote from: BlackHatCoiner on July 24, 2022, 04:01:50 AM

Quote from: vv181 on July 23, 2022, 11:41:54 PM

Raspibolt bitcoin user management doesn't make root accessible.

I've used to run chmod 777 to give all permissions. Bad practice? Lips sealed

Quote from: vv181 on July 23, 2022, 11:41:54 PM

Maybe, changing the permission to the default one could give any luck.

Tried, but no lightning at the end of the tunnel.

Quote from: n0nce on July 23, 2022, 10:13:06 AM

What stands out at first is that your node somehow creates an IPv4 listener, but still tries to use Tor somehow.

At the time it was working, I had run a getinfo, and seen it listened on both 9735 (from Tor) and 9835 (from IPv4). I don't know if that's relevant.

Okay, so no sense of what has gone wrong. Plan C: Take my money back and hit the self-destruction button. If I force-close the channel, will I get access to the funds with no lightning daemon running?

Hi. Can you wait until maybe after my lunch? I think we can try a fee other things before you go Mission Impossible with the destruct íon button. xD
Like, we can try to run only your problematic node with your main nide shut down and in the default port. Or we can try to check which ports are being used when you have your 2 nodes running to see what traffic is going where with nmap.

Another note is that this message

Code:

2022-07-17T18:36:04.268Z DEBUG gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds

is not bad. If I'm not mistaken, fds is a file descriptor and in C, a return value of zero is usually sign that things are ok, zero errors.

In Core Lightning github, there is a list with a description of a bunch of these messages. @_Rath knows is almost for sure out of his memory. I have to look for it. Maybe we can find the description for that message and we get an hint what what it really means to make sure there is no problem there.

n0nce

hero member

Activity: 882

Merit: 5834

not your keys, not your coins!

Quote from: BlackHatCoiner on July 28, 2022, 05:31:00 AM

I've restored my hsm_secret to a brand new lightning node. I had previously force-closed my personal channel, so hsm_secret is enough to access the on-chain funds. Okay, so what's the next step? I run listfunds with the old hsm_secret and get nothing:

Code:

bitcoin@raspibolt:~/.lightningmobile2/bitcoin $ lightning-cli --lightning-dir=/home/bitcoin/.lightningmobile2 --conf=/home/bitcoin/.lightningmobile2/lightningd.conf listfunds
{
"outputs": [],
"channels": []
}

My main node has received the 150,000 sats.

BTW: It turns out that the sqlite3 file was the problem. I tried to use that old one, instead of the new, automatically created sqlite3. With the new, daemon starts normally. With the old, it's when I see it stuck.

Still nothing? If I understand correctly, you had a single channel with your other node.
Your other (working) node initiated the force close and already received its part of the channel balance on-chain, confirmed?

It's normal that a force close takes some time to be completed, but if the working node already got the funds, I'm pretty certain the other one should get them at the same time, too. Maybe Rath_ can confirm.
By the way: get your node back up, Rath_! Wink

It went offline again a few days ago..

dkbit98

legendary

Activity: 2212

Merit: 7064

Is anyone collecting links for all the open source payment processors that are supporting Lightning payments?
I know BTCPay server is probably the best option if you want to accept payments in Bitcoin and LN, but it can he heavier and more complicated to set up.
One alternative option I found before was Cypherpunkpay.org, but recently I found one more open source option called SatSale.
Code has MIT license, it's lightweight and written in Python, and it can accept on-chain and Lightning payments without any middleman or third party.

SatSale is still in early development but I like that we are starting to see more open source options, that will only improve overall ecosystem.
There is a demo page you can check to see how everything works:
https://try.satsale.org/

https://github.com/SatSale/SatSale

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

I've restored my hsm_secret to a brand new lightning node. I had previously force-closed my personal channel, so hsm_secret is enough to access the on-chain funds. Okay, so what's the next step? I run listfunds with the old hsm_secret and get nothing:

Code:

bitcoin@raspibolt:~/.lightningmobile2/bitcoin $ lightning-cli --lightning-dir=/home/bitcoin/.lightningmobile2 --conf=/home/bitcoin/.lightningmobile2/lightningd.conf listfunds
{
"outputs": [],
"channels": []
}

My main node has received the 150,000 sats.

BTW: It turns out that the sqlite3 file was the problem. I tried to use that old one, instead of the new, automatically created sqlite3. With the new, daemon starts normally. With the old, it's when I see it stuck.

n0nce

hero member

Activity: 882

Merit: 5834

not your keys, not your coins!

Quote from: BlackHatCoiner on July 24, 2022, 04:01:50 AM

Okay, so no sense of what has gone wrong. Plan C: Take my money back and hit the self-destruction button. If I force-close the channel, will I get access to the funds with no lightning daemon running?

I haven't had to restore a node yet, but force-closing a channel (from the other node of course), will send the funds to your node's on-chain wallet.
You can restore that using hsm-secret.

Here is more information on Core Lightning backups:
https://lightning.readthedocs.io/BACKUP.html

psycodad

legendary

Activity: 1612

Merit: 1608

精神分析的爸

Quote from: ABCbits on July 24, 2022, 07:39:56 AM

Quote from: LoyceV on July 24, 2022, 06:06:59 AM

And of course I restrict user's home directories as much as possible (usually 700 or occasionally 750).

Do you ever see any application broke when you use 700? Usually i'd use 750.

In most standard situation it makes no difference as it's the users own group owning his home directory. It starts to become interesting when your primary group has more than one member or you chown the group ownership of your home directory to some group with more than yourself as member. In the vast majority of standard setups both settings have an identical effect.

One thing to note is that omitting all access from world/other (the third byte) breaks certain things, like ssh key-auth or mail forwarding. So I've seen 751 or 711 as recommended alternative to 750/700 [1][2].

HTH

[1] https://unix.stackexchange.com/questions/315799/default-permissions-on-linux-home-directories
[2] https://unix.stackexchange.com/questions/95897/permissions-755-on-home-user

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: ABCbits on July 24, 2022, 07:39:56 AM

Do you ever see any application broke when you use 700? Usually i'd use 750.

I must admit I don't usually use 700 for executables, but mostly for files. For most programs 755 is totally fine, and I haven't used 700 often enough to see if it breaks things, but I wouldn't do it to system files. Several services run from a different user, and that can't happen if they can't access the files they need.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: BlackHatCoiner on July 24, 2022, 04:01:50 AM

Quote from: vv181 on July 23, 2022, 11:41:54 PM

Raspibolt bitcoin user management doesn't make root accessible.

I've used to run chmod 777 to give all permissions. Bad practice? Lips sealed

I'd say it's horrible practice. It could break application which have very strict permission check, although i'm not sure any LN implementation has such strict permission check. I remember my acquaintance broke their OS by chmod 777 /.

Quote from: LoyceV on July 24, 2022, 06:06:59 AM

And of course I restrict user's home directories as much as possible (usually 700 or occasionally 750).

Do you ever see any application broke when you use 700? Usually i'd use 750.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: BlackHatCoiner on July 24, 2022, 04:01:50 AM

Quote from: vv181 on July 23, 2022, 11:41:54 PM

Raspibolt bitcoin user management doesn't make root accessible.

I've used to run chmod 777 to give all permissions. Bad practice? Lips sealed

Quite bad

I usually go for 755, I'd never give other users write-access to files owned by root. And of course I restrict user's home directories as much as possible (usually 700 or occasionally 750).

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: vv181 on July 23, 2022, 11:41:54 PM

Raspibolt bitcoin user management doesn't make root accessible.

I've used to run chmod 777 to give all permissions. Bad practice? Lips sealed

Quote from: vv181 on July 23, 2022, 11:41:54 PM

Maybe, changing the permission to the default one could give any luck.

Tried, but no lightning at the end of the tunnel.

Quote from: n0nce on July 23, 2022, 10:13:06 AM

What stands out at first is that your node somehow creates an IPv4 listener, but still tries to use Tor somehow.

At the time it was working, I had run a getinfo, and seen it listened on both 9735 (from Tor) and 9835 (from IPv4). I don't know if that's relevant.

Okay, so no sense of what has gone wrong. Plan C: Take my money back and hit the self-destruction button. If I force-close the channel, will I get access to the funds with no lightning daemon running?

vv181

legendary

Activity: 1932

Merit: 1273

Quote from: BlackHatCoiner on July 23, 2022, 08:31:18 AM

~

AFAIK, Raspibolt bitcoin user management doesn't make root accessible. Which ideally the lightningd should be exited due to a permission error, but that's not in your case. Huh

Maybe, changing the permission to the default one could give any luck. Otherwise, I don't know where else to debug, n0nce post should point out where it's wrong, I got a similar start-up sequence with it.

Quote from: n0nce on July 23, 2022, 10:13:06 AM

Code:

DEBUG connectd: connectd_init_done
INFO plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
DEBUG lightningd: All Bitcoin plugin commands registered

The default file permission:

Code:

chown bitcoin:bitcoin /home/bitcoin/.lightningmobile/lightningd.sqlite3
chmod 644 /home/bitcoin/.lightningmobile/lightningd.sqlite3

n0nce

hero member

Activity: 882

Merit: 5834

not your keys, not your coins!

Quote from: BlackHatCoiner on July 23, 2022, 08:31:18 AM

I run the lightningd, debug.log stucks at the "gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY" message again. Specifically:

Code:

2022-07-23T12:23:33.265Z DEBUG lightningd: Opened log file /home/bitcoin/.lightningmobile/debug.log
2022-07-23T12:23:33.265Z DEBUG lightningd: Opened log file /home/bitcoin/.lightningmobile/debug.log
2022-07-23T12:23:33.273Z DEBUG plugin-manager: started(31731) /usr/local/bin/../libexec/c-lightning/plugins/autoclean
2022-07-23T12:23:33.283Z DEBUG plugin-manager: started(31732) /usr/local/bin/../libexec/c-lightning/plugins/bcli
2022-07-23T12:23:33.291Z DEBUG plugin-manager: started(31733) /usr/local/bin/../libexec/c-lightning/plugins/fetchinvoice
2022-07-23T12:23:33.300Z DEBUG plugin-manager: started(31734) /usr/local/bin/../libexec/c-lightning/plugins/funder
2022-07-23T12:23:33.322Z DEBUG plugin-manager: started(31735) /usr/local/bin/../libexec/c-lightning/plugins/topology
2022-07-23T12:23:33.351Z DEBUG plugin-manager: started(31736) /usr/local/bin/../libexec/c-lightning/plugins/keysend
2022-07-23T12:23:33.372Z DEBUG plugin-manager: started(31737) /usr/local/bin/../libexec/c-lightning/plugins/offers
2022-07-23T12:23:33.392Z DEBUG plugin-manager: started(31738) /usr/local/bin/../libexec/c-lightning/plugins/pay
2022-07-23T12:23:33.417Z DEBUG plugin-manager: started(31739) /usr/local/bin/../libexec/c-lightning/plugins/txprepare
2022-07-23T12:23:33.442Z DEBUG plugin-manager: started(31740) /usr/local/bin/../libexec/c-lightning/plugins/spenderp
2022-07-23T12:23:33.580Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_channeld
2022-07-23T12:23:33.600Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_closingd
2022-07-23T12:23:33.622Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_connectd
2022-07-23T12:23:33.642Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_gossipd
2022-07-23T12:23:33.663Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_hsmd
2022-07-23T12:23:33.684Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_onchaind
2022-07-23T12:23:33.705Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_openingd
2022-07-23T12:23:33.726Z DEBUG hsmd: pid 31748, msgfd 39
2022-07-23T12:23:34.010Z DEBUG connectd: pid 31749, msgfd 43
2022-07-23T12:23:34.011Z DEBUG hsmd: new_client: 0
2022-07-23T12:23:34.104Z DEBUG connectd: Proxy address: 127.0.0.1:9050
2022-07-23T12:23:34.104Z DEBUG connectd: Created IPv4 listener on port 9835
2022-07-23T12:23:34.104Z DEBUG connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds
2022-07-23T12:23:34.109Z DEBUG gossipd: pid 31750, msgfd 42
2022-07-23T12:23:34.110Z DEBUG hsmd: new_client: 0
2022-07-23T12:23:34.203Z DEBUG gossipd: gossip_store_compact_offline: 0 deleted, 0 copied
2022-07-23T12:23:34.203Z DEBUG gossipd: total store load time: 0 msec
2022-07-23T12:23:34.204Z DEBUG gossipd: gossip_store: Read 0/0/0/0 cannounce/cupdate/nannounce/cdelete from store (0 deleted) in 1 bytes
2022-07-23T12:23:34.204Z DEBUG gossipd: seeker: state = STARTING_UP New seeker
2022-07-23T12:23:34.204Z DEBUG gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds

Alright, I just compared with my node's startup sequence and there are a few notable differences.
Three dots stand for a bunch of lines which I truncated, empty on one side means that that's something only the other user has in his log file.

What stands out at first is that your node somehow creates an IPv4 listener, but still tries to use Tor somehow. It's possible that this is the normal behaviour if you followed Core Lightning's Tor setup guide, though. I'm not sure since I have my own way of doing that. That could be something you may want to try. Basically manually creating a Tor service and tunneling the Lightning traffic through it.

Next up, I notice your connectd_init_done isn't executed, as well as much later in the process, the 'Server started with public key' message is missing. Though that's an INFO message, of which you have none. I'm not sure how that's possible, since debug should be a higher log level than info.

Code:

BlackHatCoiner n0nce

DEBUG connectd: Proxy address: 127.0.0.1:9050 DEBUG connectd: Proxy address: 127.0.0.1:9050
DEBUG connectd: Created IPv4 listener on port 9835 DEBUG connectd: Created listener on 127.0.0.1:9735
DEBUG connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds DEBUG connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds
DEBUG connectd: connectd_init_done
INFO plugin-bcli: bitcoin-cli initialized and connected to bitcoind.
DEBUG lightningd: All Bitcoin plugin commands registered
...
DEBUG gossipd: pid 31750, msgfd 43 DEBUG gossipd: pid 18646, msgfd 46
...
DEBUG hsmd: new_client: 0 DEBUG hsmd: new_client: 0
...
DEBUG gossipd: gossip_store_compact_offline: 0 deleted, 0 copied DEBUG gossipd: gossip_store_compact_offline: 350 deleted, 329864 copied
...
DEBUG gossipd: total store load time: 0 msec
DEBUG gossipd: gossip_store: Read 0/0/0/0 cannounce/cupdate/nannounce/cdelete from store (0 deleted) in 1 bytes
DEBUG gossipd: seeker: state = STARTING_UP New seeker
DEBUG connectd: REPLY WIRE_CONNECTD_ACTIVATE_REPLY with 0 fds
INFO lightningd: --------------------------------------------------
INFO lightningd: Server started with public key [redacted]
DEBUG gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds DEBUG gossipd: REPLY WIRE_GOSSIPD_GET_ADDRS_REPLY with 0 fds

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

I renamed the new lightningd.sqlite3 to lightningd.sqlite4, copied the old lightningd.sqlite3 (which grants me access to the channel) to the bitcoin directory.

Like that:

I run the lightningd, debug.log stucks at the "gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY" message again. Specifically:

Code:

2022-07-23T12:23:33.265Z DEBUG lightningd: Opened log file /home/bitcoin/.lightningmobile/debug.log
2022-07-23T12:23:33.265Z DEBUG lightningd: Opened log file /home/bitcoin/.lightningmobile/debug.log
2022-07-23T12:23:33.273Z DEBUG plugin-manager: started(31731) /usr/local/bin/../libexec/c-lightning/plugins/autoclean
2022-07-23T12:23:33.283Z DEBUG plugin-manager: started(31732) /usr/local/bin/../libexec/c-lightning/plugins/bcli
2022-07-23T12:23:33.291Z DEBUG plugin-manager: started(31733) /usr/local/bin/../libexec/c-lightning/plugins/fetchinvoice
2022-07-23T12:23:33.300Z DEBUG plugin-manager: started(31734) /usr/local/bin/../libexec/c-lightning/plugins/funder
2022-07-23T12:23:33.322Z DEBUG plugin-manager: started(31735) /usr/local/bin/../libexec/c-lightning/plugins/topology
2022-07-23T12:23:33.351Z DEBUG plugin-manager: started(31736) /usr/local/bin/../libexec/c-lightning/plugins/keysend
2022-07-23T12:23:33.372Z DEBUG plugin-manager: started(31737) /usr/local/bin/../libexec/c-lightning/plugins/offers
2022-07-23T12:23:33.392Z DEBUG plugin-manager: started(31738) /usr/local/bin/../libexec/c-lightning/plugins/pay
2022-07-23T12:23:33.417Z DEBUG plugin-manager: started(31739) /usr/local/bin/../libexec/c-lightning/plugins/txprepare
2022-07-23T12:23:33.442Z DEBUG plugin-manager: started(31740) /usr/local/bin/../libexec/c-lightning/plugins/spenderp
2022-07-23T12:23:33.580Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_channeld
2022-07-23T12:23:33.600Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_closingd
2022-07-23T12:23:33.622Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_connectd
2022-07-23T12:23:33.642Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_gossipd
2022-07-23T12:23:33.663Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_hsmd
2022-07-23T12:23:33.684Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_onchaind
2022-07-23T12:23:33.705Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_openingd
2022-07-23T12:23:33.726Z DEBUG hsmd: pid 31748, msgfd 39
2022-07-23T12:23:34.010Z DEBUG connectd: pid 31749, msgfd 43
2022-07-23T12:23:34.011Z DEBUG hsmd: new_client: 0
2022-07-23T12:23:34.104Z DEBUG connectd: Proxy address: 127.0.0.1:9050
2022-07-23T12:23:34.104Z DEBUG connectd: Created IPv4 listener on port 9835
2022-07-23T12:23:34.104Z DEBUG connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds
2022-07-23T12:23:34.109Z DEBUG gossipd: pid 31750, msgfd 42
2022-07-23T12:23:34.110Z DEBUG hsmd: new_client: 0
2022-07-23T12:23:34.203Z DEBUG gossipd: gossip_store_compact_offline: 0 deleted, 0 copied
2022-07-23T12:23:34.203Z DEBUG gossipd: total store load time: 0 msec
2022-07-23T12:23:34.204Z DEBUG gossipd: gossip_store: Read 0/0/0/0 cannounce/cupdate/nannounce/cdelete from store (0 deleted) in 1 bytes
2022-07-23T12:23:34.204Z DEBUG gossipd: seeker: state = STARTING_UP New seeker
2022-07-23T12:23:34.204Z DEBUG gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds

vv181

legendary

Activity: 1932

Merit: 1273

Quote from: BlackHatCoiner on July 23, 2022, 07:41:07 AM

Is it lightningd.sqlite3?

Yes. If the database file has other files that end with a -journal or -wal files, copy those too.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Which file contains the keys that grant me access to the channel? I have opened one private channel with my main node, worth of 300,000 sats. I've sent 150,000 sats, to make it balance, but I now want to empty it and retry, from a brand new node. Is it lightningd.sqlite3?

I have renamed ./lightningmobile/bitcoin to ./lightningmobile/bitcoin2, ran lightningd again, and it created a new bitcoin directory. The "Server started with public key x" appeared, but it currently has 0 channels. So, the access to the channel must be at bitcoin2. Note that the lightning-rpc isn't located at ./lightningmobile, but at ./lightningmobile/bitcoin for some reason I don't understand.

---------------
I'm far away from home and do everything with SSH via Tor. It goes so slowly...

vv181

legendary

Activity: 1932

Merit: 1273

Quote from: n0nce on July 22, 2022, 04:22:21 PM

it appears to me that it does start up, just that lightning-cli has issues connecting to the RPC interface.

I hardly understand C^[1], but I doubt it finished up the start-up process until it shows the output I mentioned above. @BCH could try to confirm it by deleting the lightning-rpc file and restarting the lightningd, if the file didn't get initialised I think it stuck on the gossip initialisation things.

@BlackHatCoiner, it is weird that on the first hand the node is working successfully but now isn't. Looking through the GitHub issues, issue #4810 which lead to #4822 is the closer that you got since it has a similar log that stuck at "REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds". But I don't think it has something to do with yours since those issues are relating to BTCPay Server or -plugindir, and also your main node is working fine.

I don't know where else to debug, but if I were you, see if the gossip_store file is safe to delete. If it is, I might just simply delete it, and try to run lightningd again. #4810 also has some way to trace/debug it further in case you are interested.

n0nce

hero member

Activity: 882

Merit: 5834

not your keys, not your coins!

Quote from: BlackHatCoiner on July 22, 2022, 02:06:15 PM

Quote from: n0nce on July 18, 2022, 10:44:30 AM

Easiest way to confirm that ports are the issue would be to shut down the main Core Lightning node and then start the lightningmobile one.

Tried it. The issue wasn't resolved. The mobile node couldn't startup.

From the log file and the behaviour of the SSH session where you start up the node, it appears to me that it does start up, just that lightning-cli has issues connecting to the RPC interface.
One way to make sure the node is running would be to have someone attempt opening a channel with your node or sending it a payment, just to make sure it's online.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: vv181 on July 18, 2022, 02:09:26 AM

@BlackHatCoiner, does when you start the node, the debug show any output that starts with "Server started with public key xxx"?

No. I'm running two SSH sessions right now, one with lightningd and another with tail-ing the debug.log.

1:

Code:

bitcoin@raspibolt:~ $ lightningd --conf=/home/bitcoin/.lightningmobile/lightningd.conf --lightning-dir=/home/bitcoin/.lightningmobile

(stuck here)

2:

Code:

bitcoin@raspibolt:~ $ sudo tail -f /home/bitcoin/.lightningmobile/debug.log
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 723785x2343x1/1 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 741095x1126x0/1 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 741095x1031x1/1 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 738602x974x1/0 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 741095x541x0/1 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 710043x428x0/1 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 738602x969x1/1 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 731109x1119x0/0 now ACTIVE
2022-07-17T18:36:04.267Z DEBUG gossipd: Received channel_update for channel 716516x843x0/0 now ACTIVE
2022-07-17T18:36:04.268Z DEBUG gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds

2022-07-22T17:57:29.684Z DEBUG lightningd: Opened log file /home/bitcoin/.lightningmobile/debug.log
2022-07-22T17:57:29.684Z DEBUG lightningd: Opened log file /home/bitcoin/.lightningmobile/debug.log
2022-07-22T17:57:29.693Z DEBUG plugin-manager: started(23544) /usr/local/bin/../libexec/c-lightning/plugins/autoclean
2022-07-22T17:57:29.701Z DEBUG plugin-manager: started(23545) /usr/local/bin/../libexec/c-lightning/plugins/bcli
2022-07-22T17:57:29.710Z DEBUG plugin-manager: started(23546) /usr/local/bin/../libexec/c-lightning/plugins/fetchinvoice
2022-07-22T17:57:29.718Z DEBUG plugin-manager: started(23547) /usr/local/bin/../libexec/c-lightning/plugins/funder
2022-07-22T17:57:29.751Z DEBUG plugin-manager: started(23548) /usr/local/bin/../libexec/c-lightning/plugins/topology
2022-07-22T17:57:29.768Z DEBUG plugin-manager: started(23549) /usr/local/bin/../libexec/c-lightning/plugins/keysend
2022-07-22T17:57:29.792Z DEBUG plugin-manager: started(23550) /usr/local/bin/../libexec/c-lightning/plugins/offers
2022-07-22T17:57:29.812Z DEBUG plugin-manager: started(23551) /usr/local/bin/../libexec/c-lightning/plugins/pay
2022-07-22T17:57:29.838Z DEBUG plugin-manager: started(23552) /usr/local/bin/../libexec/c-lightning/plugins/txprepare
2022-07-22T17:57:29.852Z DEBUG plugin-manager: started(23553) /usr/local/bin/../libexec/c-lightning/plugins/spenderp
2022-07-22T17:57:30.013Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_channeld
2022-07-22T17:57:30.038Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_closingd
2022-07-22T17:57:30.072Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_connectd
2022-07-22T17:57:30.101Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_gossipd
2022-07-22T17:57:30.129Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_hsmd
2022-07-22T17:57:30.157Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_onchaind
2022-07-22T17:57:30.193Z DEBUG lightningd: testing /usr/local/libexec/c-lightning/lightning_openingd
2022-07-22T17:57:30.224Z DEBUG hsmd: pid 23562, msgfd 39
2022-07-22T17:57:30.774Z DEBUG connectd: pid 23563, msgfd 43
2022-07-22T17:57:30.775Z DEBUG hsmd: new_client: 0
2022-07-22T17:57:30.875Z DEBUG connectd: Proxy address: 127.0.0.1:9050
2022-07-22T17:57:30.875Z DEBUG connectd: Created IPv4 listener on port 9835
2022-07-22T17:57:30.876Z DEBUG connectd: REPLY WIRE_CONNECTD_INIT_REPLY with 0 fds
2022-07-22T17:57:30.880Z DEBUG gossipd: pid 23564, msgfd 42
2022-07-22T17:57:30.881Z DEBUG hsmd: new_client: 0
2022-07-22T17:57:35.826Z DEBUG gossipd: gossip_store_compact_offline: 0 deleted, 22662 copied
2022-07-22T17:57:35.826Z DEBUG gossipd: Received channel_update for channel 738586x899x1/1 now ACTIVE
2022-07-22T17:57:35.831Z DEBUG gossipd: Received channel_update for channel 738586x1081x1/1 now ACTIVE
2022-07-22T17:57:35.831Z DEBUG gossipd: Received channel_update for channel 739408x2208x0/1 now ACTIVE
2022-07-22T17:57:35.832Z DEBUG gossipd: Received channel_update for channel 731109x938x1/0 now ACTIVE
2022-07-22T17:57:35.832Z DEBUG gossipd: Received channel_update for channel 700393x896x0/0 now ACTIVE
2022-07-22T17:57:35.832Z DEBUG gossipd: Received channel_update for channel 718348x836x0/0 now ACTIVE
2022-07-22T17:57:35.832Z DEBUG gossipd: Received channel_update for channel 737921x1833x0/0 now ACTIVE
2022-07-22T17:57:35.832Z DEBUG gossipd: Received channel_update for channel 724642x918x1/0 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 741095x1108x0/1 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 736890x1413x0/1 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 723785x1459x1/0 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 723785x2343x1/1 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 741095x1126x0/1 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 741095x1031x1/1 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 738602x974x1/0 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 741095x541x0/1 now ACTIVE
2022-07-22T17:57:35.833Z DEBUG gossipd: Received channel_update for channel 710043x428x0/1 now ACTIVE
2022-07-22T17:57:35.834Z DEBUG gossipd: Received channel_update for channel 738602x969x1/1 now ACTIVE
2022-07-22T17:57:35.834Z DEBUG gossipd: Received channel_update for channel 731109x1119x0/0 now ACTIVE
2022-07-22T17:57:35.834Z DEBUG gossipd: Received channel_update for channel 716516x843x0/0 now ACTIVE
2022-07-22T17:57:35.834Z DEBUG gossipd: REPLY WIRE_GOSSIPD_INIT_REPLY with 0 fds

Quote from: darkv0rt3x on July 17, 2022, 03:22:54 PM

I'm not sure about this, but in one of those 2 stackexchange links I sent in a few posts above, someone says that we have to set different ports for RPC.

It did work at first. Then, it suddenly stopped working. I've had my two lightning nodes running for a few minutes. Besides, they already do listen to different ports. (9735, 9835)

Quote from: n0nce on July 18, 2022, 10:44:30 AM

Easiest way to confirm that ports are the issue would be to shut down the main Core Lightning node and then start the lightningmobile one.

Tried it. The issue wasn't resolved. The mobile node couldn't startup.

darkv0rt3x

hero member

Activity: 1260

Merit: 675

I rather die on my feet than to live on my knees

Quote from: n0nce on July 18, 2022, 10:44:30 AM

Quote from: BlackHatCoiner on July 17, 2022, 02:37:03 PM

Code:

bitcoin@raspibolt:~ $ lightningd --conf=/home/bitcoin/.lightningmobile/lightningd.conf --lightning-dir=/home/bitcoin/.lightningmobile

----
(stuck doesn't do anything)

It being 'stuck' is actually what you want, to be honest. That's what normally happens when you run lightningd from the command line without --daemon parameter.
Have you tried, while it's stuck, e.g. in another tmux window or other SSH session, to then execute lightning-cli with the same --lightning-dir?

Quote from: darkv0rt3x on July 17, 2022, 03:22:54 PM

I'm not sure about this, but in one of those 2 stackexchange links I sent in a few posts above, someone says that we have to set different ports for RPC. I'm not sure if he meant for Bitcoin deamon or for the lightnind daemon.
The OP end up answering himself with this:

Quote

Listen addresses must be different, eg. 0.0.0.0:9735 and 0.0.0.0:9736, and both need to be open in router. Also rpclisten must be different, eg: 127.0.0.1:10009 and 127.0.0.1:10019

Going to check my config files of both Bitcoin Core and Core Lightning to se if I have this setting in any of them!

Yes, I do remember when I had both a Testnet and Mainnet node, that I had to use different ports indeed. May have changed by now, may not, may be a different issue entirely - not sure, but good thing to check.
Easiest way to confirm that ports are the issue would be to shut down the main Core Lightning node and then start the lightningmobile one.

We tried to address it out of Bitcointalk, via Telegram. @BlackHatCoiner thought that that "stuck" state was not good and therefore he SIGINT the deamon.

I suggested him to use either screen or tmux to run the daemon and be able to use the same terminal or at least, run the daemon with:

Code:

lightningd --conf=/home/bitcoin/.lightningmobile/lightningd.conf --lightning-dir=/home/bitcoin/.lightningmobile &

Which brings the prompt back to his control. However, he end up not having time to continue the debug, so whenever he wants/have time, we can continue it unless he figured it out already!

n0nce

hero member

Activity: 882

Merit: 5834

not your keys, not your coins!

Quote from: BlackHatCoiner on July 17, 2022, 02:37:03 PM

Code:

bitcoin@raspibolt:~ $ lightningd --conf=/home/bitcoin/.lightningmobile/lightningd.conf --lightning-dir=/home/bitcoin/.lightningmobile

----
(stuck doesn't do anything)

It being 'stuck' is actually what you want, to be honest. That's what normally happens when you run lightningd from the command line without --daemon parameter.
Have you tried, while it's stuck, e.g. in another tmux window or other SSH session, to then execute lightning-cli with the same --lightning-dir?

Quote from: darkv0rt3x on July 17, 2022, 03:22:54 PM

I'm not sure about this, but in one of those 2 stackexchange links I sent in a few posts above, someone says that we have to set different ports for RPC. I'm not sure if he meant for Bitcoin deamon or for the lightnind daemon.
The OP end up answering himself with this:

Quote

Listen addresses must be different, eg. 0.0.0.0:9735 and 0.0.0.0:9736, and both need to be open in router. Also rpclisten must be different, eg: 127.0.0.1:10009 and 127.0.0.1:10019

Going to check my config files of both Bitcoin Core and Core Lightning to se if I have this setting in any of them!

Yes, I do remember when I had both a Testnet and Mainnet node, that I had to use different ports indeed. May have changed by now, may not, may be a different issue entirely - not sure, but good thing to check.
Easiest way to confirm that ports are the issue would be to shut down the main Core Lightning node and then start the lightningmobile one.

Topic: The Lightning Network FAQ - page 13. (Read 33222 times)