search

BlueWallet / LndHub

Wrapper for Lightning Network Daemon. It provides separate accounts for end-users
http://LndHub.io
MIT License
784 stars 198 forks source link

LNDhub 1.3 on myNode failing often #161

Open godSaysHODL opened 3 years ago

godSaysHODL commented 3 years ago

having to restart LNDhub almost daily. Wallet gets code 7 error if I'm creating an invoice, or code 4 if I'm paying an invoice. I goto lndhub address to investigate, and lndhub officially fails and restarts itself to work again properly. Only been happening since 1.3 update.

-- Logs begin at Wed 2021-03-24 05:42:39 CDT, end at Wed 2021-03-24 19:01:18 CDT. -- Mar 24 19:00:58 myNode systemd[1]: lndhub.service: Failed with result 'exit-code'. Mar 24 19:00:58 myNode systemd[1]: lndhub.service: Main process exited, code=exited, status=3/NOTIMPLEMENTED Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! /home/bitcoin/.npm/_logs/2021-03-25T00_00_58_882Z-debug.log Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! A complete log of this run can be found in: Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! This is probably not a problem with npm. There is likely additional logging output above. Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! Failed at the lndhub@1.3.0 start script. Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! Exit status 3 Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! lndhub@1.3.0 start: babel-node index.js Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! errno 3 Mar 24 19:00:58 myNode lndhub[30998]: npm ERR! code ELIFECYCLE Mar 24 19:00:58 myNode lndhub[30998]: lnd failure Mar 24 19:00:58 myNode lndhub[30998]: 2021-03-25T00:00:58.309Z : info: [/] : ["673669fe-bb87-4c59-b59d-12246927b69f"] Mar 24 19:00:57 myNode lndhub[30998]: metadata: Metadata { internalRepr: Map {}, options: {} } } Mar 24 19:00:57 myNode lndhub[30998]: details: 'Bandwidth exhausted', Mar 24 19:00:57 myNode lndhub[30998]: code: 8, Mar 24 19:00:57 myNode lndhub[30998]: at processTicksAndRejections (internal/process/task_queues.js:79:9) Mar 24 19:00:57 myNode lndhub[30998]: at process.nextTick (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call-stream.ts:249:24) Mar 24 19:00:57 myNode lndhub[30998]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48) Mar 24 19:00:57 myNode lndhub[30998]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34) Mar 24 19:00:57 myNode lndhub[30998]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client.ts:334:36) Mar 24 19:00:57 myNode lndhub[30998]: at Object.callErrorFromStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call.ts:81:24) Mar 24 19:00:57 myNode lndhub[30998]: lnd failure: { Error: 8 RESOURCE_EXHAUSTED: Bandwidth exhausted Mar 24 19:00:57 myNode lndhub[30998]: metadata: Metadata { internalRepr: Map {}, options: {} } } Mar 24 19:00:57 myNode lndhub[30998]: details: 'Bandwidth exhausted', Mar 24 19:00:57 myNode lndhub[30998]: code: 8, Mar 24 19:00:57 myNode lndhub[30998]: at processTicksAndRejections (internal/process/task_queues.js:79:9) Mar 24 19:00:57 myNode lndhub[30998]: at process.nextTick (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call-stream.ts:249:24) Mar 24 19:00:57 myNode lndhub[30998]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48) Mar 24 19:00:57 myNode lndhub[30998]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34) Mar 24 19:00:57 myNode lndhub[30998]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client.ts:334:36) Mar 24 19:00:57 myNode lndhub[30998]: at Object.callErrorFromStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call.ts:81:24) Mar 24 19:00:57 myNode lndhub[30998]: lnd failure: { Error: 8 RESOURCE_EXHAUSTED: Bandwidth exhausted

xraid commented 3 years ago

COMMENT OUT THE LINES no. 5 6 7 :

in LndHub/config.js = // bitcoin 3 lines

restart

DONE

just works ™

told You so already on the on 2 Apr . YOU godSaysHODL are SLOW, very SLOW ...

tehelsper commented 3 years ago

Next myNode release will have the bitcoind section commented out. I tested locally and it seemed to work well and another user that was having issues saw improvements as well.

Are there downsides to not including the bitcoind section? If not, why is it still there?

godSaysHODL commented 3 years ago

Screenshot_20210512-221018

Got a response that may help in this screenshot^ I will try this. Can I edit config file easily from myNode SSH terminal?

Still getting failures after these lines have been commented out and restarted

Overtorment commented 3 years ago

Next myNode release will have the bitcoind section commented out. I tested locally and it seemed to work well and another user that was having issues saw improvements as well.

Are there downsides to not including the bitcoind section? If not, why is it still there?

for heavy usage (like our production lndhub) bitcoind is used to track balances, instead of lnd's internal wallet

blankscreengithub commented 3 years ago

LndHub is still crashing everyday with this error even on version 1.3.5. See my logs below for LndHub and lnd.

This issue has also shown up here and someone fixed it switching from grpc-js to grpc: [https://github.com/grpc/grpc-node/issues/1158]

The hardware: Raspberry Pi 4

Current software versions: myNode 0.2.37 LND Hub v1.3.5 LND Version v0.13.0

LndHug log:

Jul 05 23:26:15 myNode lndhub[2128]: metadata: Metadata { internalRepr: Map {}, options: {} } } Jul 05 23:26:15 myNode lndhub[2128]: details: 'Bandwidth exhausted', Jul 05 23:26:15 myNode lndhub[2128]: code: 8, Jul 05 23:26:15 myNode lndhub[2128]: at processTicksAndRejections (internal/process/task_queues.js:79:9) Jul 05 23:26:15 myNode lndhub[2128]: at process.nextTick (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call-stream.ts:276:24) Jul 05 23:26:15 myNode lndhub[2128]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48) Jul 05 23:26:15 myNode lndhub[2128]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34) Jul 05 23:26:15 myNode lndhub[2128]: at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client.ts:338:36) Jul 05 23:26:15 myNode lndhub[2128]: at Object.callErrorFromStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call.ts:81:24) Jul 05 23:26:15 myNode lndhub[2128]: lnd failure: { Error: 8 RESOURCE_EXHAUSTED: Bandwidth exhausted

lnd log

Jul 05 23:37:27 myNode lnd[3668]: 2021-07-05 23:37:27.109 [INF] WTCL: (legacy) Queued backup(7200d76e53a484bae217c54fe456a9dba053f3f6d6f96a74ed89bbb2af320e08, 246) successfully for session 02dd19bd3456555c99abea18c8ad4ac8a21942cc691334ecb6a79d61660fdbc541 Jul 05 23:37:26 myNode lnd[3668]: 2021-07-05 23:37:26.155 [ERR] HSWC: Unhandled error while reforwarding htlc settle/fail over htlcswitch: insufficient bandwidth to route htlc Jul 05 23:37:26 myNode lnd[3668]: 2021-07-05 23:37:26.154 [ERR] HSWC: insufficient bandwidth to route htlc Jul 05 23:37:26 myNode lnd[3668]: 2021-07-05 23:37:26.111 [INF] WTCL: (legacy) Queued backup(7200d76e53a484bae217c54fe456a9dba053f3f6d6f96a74ed89bbb2af320e08, 245) successfully for session 02dd19bd3456555c99abea18c8ad4ac8a21942cc691334ecb6a79d61660fdbc541 Jul 05 23:37:09 myNode lnd[3668]: 2021-07-05 23:37:09.774 [INF] WTCL: (anchor) Client stats: tasks(received=0 accepted=0 ineligible=0) sessions(acquired=0 exhausted=0) Jul 05 23:37:09 myNode lnd[3668]: 2021-07-05 23:37:09.749 [INF] WTCL: (legacy) Client stats: tasks(received=0 accepted=188 ineligible=0) sessions(acquired=0 exhausted=0)

Overtorment commented 3 years ago

@blankscreengithub even lnd is complaining about "bandwidth" Jul 05 23:37:26 myNode lnd[3668]: 2021-07-05 23:37:26.154 [ERR] HSWC: insufficient bandwidth to route htlc

it really sounds like a problem on myNode's side

Overtorment commented 3 years ago

is it possible to rollback myNode version but keep Lndhub updated and see if the problem persists?

Overtorment commented 3 years ago

ok quick googling showed that this might be because lnd cant route a payment because there is not enough balance on some channels. its a good question why is it even trying to route if there is not enough balance.

what we could do is add termination upon this error so lndhub restarts automatically:

diff --git a/controllers/website.js b/controllers/website.js
index 7785937..7bd7804 100644
--- a/controllers/website.js
+++ b/controllers/website.js
@@ -14,6 +14,7 @@ function updateLightning() {
     lightning.getInfo({}, function (err, info) {
       if (err) {
         console.error('lnd failure:', err);
+        process.exit(4);
         return;
       }
       lightningGetInfo = info;
@@ -22,6 +23,7 @@ function updateLightning() {
     lightning.listChannels({}, function (err, response) {
       if (err) {
         console.error('lnd failure:', err);
+        process.exit(4);
         return;
       }
       console.log('updated');
@@ -98,7 +100,8 @@ router.get('/qr', function (req, res) {
   if (process.env.TOR_URL) {
     host = process.env.TOR_URL;
   }
xraid commented 3 years ago

also maybe add babel build && run node build/index can help with exhausted errs ?

since "node_modules/.bin/babel-node" as invocator is recommended against in prod

https://babeljs.io/docs/en/babel-node "You should not be using babel-node in production. It is unnecessarily heavy, with high memory usage due to the cache being stored in memory. You will also always experience a startup performance penalty as the entire app needs to be compiled on the fly."

blankscreengithub commented 3 years ago

I'll try the auto-restart idea.

I updated my website.js and added the 2 lines:

process.exit(4);

and commented out the line:

97 let host = req.headers.host;

I should know by tomorrow morning if my LndHub is running or not since it runs for almost 24 hours and then I would get the bandwidth error.

blankscreengithub commented 3 years ago

It looks like the auto-restart did its job. LndHub ran for about 20-21 hours and then hit the bandwidth exhausted error. LndHub restarted and was up and running within 2 minutes of the error. As a user, the restart didn't affect me at all.

Also, is there a particular reason the updateLightning() runs every minute? I only have a handful of users, so would there be any issues if I extend that longer (e.g. 5, 10, 15 minutes)? Could this be causing the bandwidth error?

Here is the log from the error which initiated the restart:


Jul 10 07:37:51 myNode lndhub[10925]: updateLightning()
Jul 10 07:37:51 myNode lndhub[10925]: updated
Jul 10 07:38:51 myNode lndhub[10925]: updateLightning()
Jul 10 07:38:51 myNode lndhub[10925]: updated
Jul 10 07:39:51 myNode lndhub[10925]: updateLightning()
Jul 10 07:38:51 myNode lndhub[10925]: updated
Jul 10 07:39:51 myNode lndhub[10925]: updateLightning()
Jul 10 07:39:51 myNode lndhub[10925]: lnd failure: { Error: 8 RESOURCE_EXHAUSTED: Bandwidth exhausted
Jul 10 07:39:51 myNode lndhub[10925]:     at Object.callErrorFromStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call.ts:81:24)
Jul 10 07:39:51 myNode lndhub[10925]:     at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client.ts:338:36)
Jul 10 07:39:51 myNode lndhub[10925]:     at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:426:34)
Jul 10 07:39:51 myNode lndhub[10925]:     at Object.onReceiveStatus (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/client-interceptors.ts:389:48)
Jul 10 07:39:51 myNode lndhub[10925]:     at process.nextTick (/opt/mynode/LndHub/node_modules/@grpc/grpc-js/src/call-stream.ts:276:24)
Jul 10 07:39:51 myNode lndhub[10925]:     at processTicksAndRejections (internal/process/task_queues.js:79:9)
Jul 10 07:39:51 myNode lndhub[10925]:   code: 8,
Jul 10 07:39:51 myNode lndhub[10925]:   details: 'Bandwidth exhausted',
Jul 10 07:39:51 myNode lndhub[10925]:   metadata: Metadata { internalRepr: Map {}, options: {} } }
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR! code ELIFECYCLE
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR! errno 4
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR! lndhub@1.3.5 start: `babel-node index.js`
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR! Exit status 4
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR!
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR! Failed at the lndhub@1.3.5 start script.
Jul 10 07:39:51 myNode lndhub[10925]: npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
Jul 10 07:39:52 myNode lndhub[10925]: npm ERR! A complete log of this run can be found in:
Jul 10 07:39:52 myNode lndhub[10925]: npm ERR!     /home/bitcoin/.npm/_logs/2021-07-10T12_39_51_998Z-debug.log
Jul 10 07:40:52 myNode lndhub[29791]: Checking if device is shutting down...
Jul 10 07:40:52 myNode lndhub[29791]: Not shutting down!
Jul 10 07:40:52 myNode lndhub[29808]: Checking if LND is synced...
Jul 10 07:40:53 myNode lndhub[29808]:     "synced_to_chain": true,
Jul 10 07:40:54 myNode lndhub[29834]: > lndhub@1.3.5 start /opt/mynode/LndHub
Jul 10 07:40:54 myNode lndhub[29834]: > babel-node index.js
Jul 10 07:40:59 myNode lndhub[29834]: using config {"enableUpdateDescribeGraph":false,"postRateLimit":100,"rateLimit":200,"redis":{"port":6379,"host":"127.0.0.1","family":4,"password":"","db":0},"lnd":{"url":"$
Jul 10 07:41:00 myNode lndhub[29834]: updateLightning()
Jul 10 07:41:00 myNode lndhub[29834]: 2021-07-10T12:41:00.898Z : info: [BOOTING UP] : "Listening on port 3000"
Jul 10 07:41:00 myNode lndhub[29834]: (node:29861) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verif$
Jul 10 07:41:01 myNode lndhub[29834]: updated
Overtorment commented 3 years ago

its unclear why this bandwidth error is thrown. feels like lnd's issue, that's for some reason fucks up whole communication between lnd & lndhub. updateLightning() only refreshes basic stuff, like node's getInfo & listChannels, it should not affect our app, in theory. in practice, you could make it run less frequently, as a penalty the main webpage with fancy channels list would refresh less frequently

Overtorment commented 3 years ago

also maybe add babel build && run node build/index can help with exhausted errs ?

since "node_modules/.bin/babel-node" as invocator is recommended against in prod

https://babeljs.io/docs/en/babel-node "You should not be using babel-node in production. It is unnecessarily heavy, with high memory usage due to the cache being stored in memory. You will also always experience a startup performance penalty as the entire app needs to be compiled on the fly."

good idea

lndhub-admin commented 3 years ago

mkdir build babel ./ --out-dir ./build --copy-files --ignore node_modules node build/index.js

lndhub-admin commented 3 years ago

it could be raspian OS ? compiler stack for node has some unset flag introducing skipped garbage collection or some such ? and thats why we do not se it in other environments . is a guess ...

we will know more if somebody with myNode could try ...

the above mkdir etc.

blankscreengithub commented 3 years ago

I might be able to try it. Under what directory do I run these commands?

mkdir build babel ./ --out-dir ./build --copy-files --ignore node_modules node build/index.js

lndhub-admin commented 3 years ago

in /LndHub folder

commands will create a build folder, then babel builds source into that folder, and node build/index.js runs the build with node and not with babel-node that have xtra cashes and debugs ? ++

blankscreengithub commented 3 years ago

I received an error on running babel command:

admin@myNode:/opt/mynode/LndHub $ ls
admin.macaroon  btc-decoder.js  class      controllers  Dockerfile  LICENSE       logs          package.json       README.md  run-process-locked.sh  static     tls.cert
bitcoin.js      build           config.js  doc          index.js    lightning.js  node_modules  package-lock.json  rpc.proto  scripts                templates  utils
admin@myNode:/opt/mynode/LndHub $ babel ./ --out-dir ./build --copy-files --ignore node_modules
Error: Requires Babel "^7.0.0-0", but was loaded with "6.26.3". If you are sure you have a compatible version of @babel/core, it is likely that something in your build process is loading the wrong version. Inspect the stack trace of this error to look for the first entry that doesn't mention "@babel/core" or "babel-core" to see what is calling Babel. (While processing preset: "/opt/mynode/LndHub/node_modules/@babel/preset-env/lib/index.js")
    at throwVersionError (/opt/mynode/LndHub/node_modules/@babel/helper-plugin-utils/lib/index.js:78:11)
    at Object.range [as assertVersion] (/opt/mynode/LndHub/node_modules/@babel/helper-plugin-utils/lib/index.js:28:5)
    at _default (/opt/mynode/LndHub/node_modules/@babel/preset-env/lib/index.js:250:7)
    at /opt/mynode/LndHub/node_modules/@babel/helper-plugin-utils/lib/index.js:22:12
    at /usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/options/option-manager.js:317:46
    at Array.map (<anonymous>)
    at OptionManager.resolvePresets (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/options/option-manager.js:275:20)
    at OptionManager.mergePresets (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/options/option-manager.js:264:10)
    at OptionManager.mergeOptions (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/options/option-manager.js:249:14)
    at OptionManager.init (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/options/option-manager.js:368:12)
    at File.initOptions (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/index.js:212:65)
    at new File (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/file/index.js:135:24)
    at Pipeline.transform (/usr/lib/node_modules/babel-cli/node_modules/babel-core/lib/transformation/pipeline.js:46:16)
    at transform (/usr/lib/node_modules/babel-cli/lib/babel/util.js:50:22)
    at Object.compile (/usr/lib/node_modules/babel-cli/lib/babel/util.js:59:12)
    at write (/usr/lib/node_modules/babel-cli/lib/babel/dir.js:21:21)
    at handleFile (/usr/lib/node_modules/babel-cli/lib/babel/dir.js:43:7)
    at /usr/lib/node_modules/babel-cli/lib/babel/dir.js:61:9
    at Array.forEach (<anonymous>)
    at handle (/usr/lib/node_modules/babel-cli/lib/babel/dir.js:59:29)
    at Array.forEach (<anonymous>)
    at module.exports (/usr/lib/node_modules/babel-cli/lib/babel/dir.js:69:15)
    at Object.<anonymous> (/usr/lib/node_modules/babel-cli/lib/babel/index.js:129:1)
    at Module._compile (internal/modules/cjs/loader.js:816:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
lndhub-admin commented 3 years ago

try do a

cat /opt/mynode/LndHub/package.json | grep version

to se what version of LndHub You have installed

lndhub-admin commented 3 years ago

i got errs as well when tried and then pointed at babel explicit since we do not want to use global version that might be installed

node_modules/.bin/babel ./ --out-dir ./build --copy-files --ignore node_modules

if that do not work try

npm uninstall babel npm install --save-dev babel-cli

and do the

node_modules/.bin/babel ./ --out-dir ./build --copy-files --ignore node_modules

blankscreengithub commented 3 years ago

try do a

cat /opt/mynode/LndHub/package.json | grep version

to se what version of LndHub You have installed

"version": "1.3.5",

lndhub-admin commented 3 years ago

mkdir build node_modules/.bin/babel ./ --out-dir ./build --copy-files --ignore node_modules node build/index.js

should work ? i myself do not have a myNode environment to test on

blankscreengithub commented 3 years ago

its unclear why this bandwidth error is thrown. feels like lnd's issue, that's for some reason fucks up whole communication between lnd & lndhub. updateLightning() only refreshes basic stuff, like node's getInfo & listChannels, it should not affect our app, in theory. in practice, you could make it run less frequently, as a penalty the main webpage with fancy channels list would refresh less frequently

I changed the updateLightning() interval to every 100 minutes and I never received the bandwith error in running 1.5 days where before I would get the bandwidth error at around 21 hours after restart.

I did have issues when I tried the "refill" option with a couple of wallets where the balance wouldn't show up in the wallet, but I don't know if that was tied to the update interval.

I changed my interval back to 1 minute since the auto restart is keeping LndHub running.

When I get a chance over the next couple of days, I'll try the mkdir build steps noted above.

tehelsper commented 3 years ago

Interesting. myNode also polls LND for data, but I haven't noticed dropped requests. I imagine it could see the same issue, but it just does the equivalent of an LNDHub restart when it fails by creating a completely new connection for each request. Is LNDHub using a single connection for all requests?

@blankscreengithub If you change it to 2 or 5 minutes, does that seem to help as well?

I like the restart idea or the more efficient way of launching compiling / launching.

@lndhub-admin I was able to compile and run lndhub via your instructions. However, I can't compile it ahead of time (ie pre-wallet create and setup) which would be a bit of a pain. I got this error:

bitcoin@myNode:/opt/mynode/LndHub $ node_modules/.bin/babel ./ --out-dir ./build --copy-files --ignore node_modules
{ Error: ENOENT: no such file or directory, stat 'admin.macaroon'
    at Object.statSync (fs.js:871:3)
    at _fsReaddirRecursive (/opt/mynode/LndHub/node_modules/@babel/cli/lib/babel/util.js:78:24)
    at /opt/mynode/LndHub/node_modules/fs-readdir-recursive/index.js:16:14
    at Array.filter (<anonymous>)
    at read (/opt/mynode/LndHub/node_modules/fs-readdir-recursive/index.js:15:6)
    at Object.readdir (/opt/mynode/LndHub/node_modules/@babel/cli/lib/babel/util.js:77:31)
    at /opt/mynode/LndHub/node_modules/@babel/cli/lib/babel/dir.js:160:30
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/opt/mynode/LndHub/node_modules/@babel/cli/lib/babel/dir.js:40:103)
    at _next (/opt/mynode/LndHub/node_modules/@babel/cli/lib/babel/dir.js:42:194)
  errno: -2,
  syscall: 'stat',
  code: 'ENOENT',
  path: 'admin.macaroon' }
bitcoin@myNode:/opt/mynode/LndHub $
lndhub-admin commented 3 years ago

i think You need to have admin.macaroon and tls.cert already inside the LndHub folder and also have set Your config.js . then it should build as expected . and run more efficent ...

lndhub-admin commented 3 years ago

I will soon™ try put together a repo where some changes are made in regards to run as a smaller operator, as LndHub now is made for Bluewallet's deploy environment and not for running in an standalone environment.

also then do the build and run with node while keeping running with babel-node for development.

lndhub-admin commented 3 years ago

"Is LNDHub using a single connection for all requests?"

LndHub uses gRPC (remote procedure call) for communication with LND and a call is created when LndHub API is called from a HTTP/S connected device.

Overtorment commented 3 years ago

@tehelsper @lndhub-admin yes, grpc is employed is employed, as far as I can tell its a single tcp connection that's established only once

tehelsper commented 3 years ago

@Overtorment That's what I was guessing. While it's definitely not the root cause, that is interesting. I poll at the same rate within myNode, but it uses the REST API and I've not ever LND complain about bandwidth issues.

Unfortunately, I don't have a pattern yet for app install post-wallet creation, but I could look more into it if necessary. I'm also on a relatively old version of node, but that hasn't had any major impacts yet.

Would it be possible to make the poll rate configurable and/or an option to exit or restart after gRPC failures?

Also, the one time I was seeing this issue and reproducing it, a restart of LndHub did not seem to resolve the issue. I was tweaking LND timeout values to see if it helped by restarting LND + LndHub, but the issue was returning. None of my nodes see the issue now though, which makes me think it is related to the current state of LND.

blankscreengithub commented 3 years ago

As an end user of LndHub with other people using my LndHub, the restart option is working for me. It only takes 1 minute and 8 seconds from the crash to be up and running again. If someone does happen to try to do something within that window, by the time they try again, everything will be fine.

It's not the best solution, but it is working.