Sudden 502 bad gateway #5469
-
I updated btcpay by pulling the repo. I ran build.sh. From https://github.com/btcpayserver/btcpayserver
Any ideas what might be causing this? |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 2 replies
-
I assume you are running the manual deployment and upgraded from v1.11.3? Guessing the version by the tags that have been pulled, but you might not have build and run anm earlier version. The nginx log indicates that BTCPay Server is not running or reachable, can you check the BTCPay Server and NBXplorer logs as well and see why these services might not start or fail? These commands should give you an overview: sudo journalctl -xe --unit nbxplorer
sudo journalctl -xe --unit btcpay |
Beta Was this translation helpful? Give feedback.
-
The services say they are running. I thought maybe some thing had changed from 1.7.3 to 1.11.5 ● btcpay.service - BTCPay Server ● nbxplorer.service - NBXplorer daemon systemd[1]: Started NBXplorer daemon. -- The job identifier is 939875 and the job result is done.
|
Beta Was this translation helpful? Give feedback.
-
I've also tried pulling a fresh copy of BTCPay server, and building. Made no difference. |
Beta Was this translation helpful? Give feedback.
-
Looks like it might be an issue in nbxplorer |
Beta Was this translation helpful? Give feedback.
-
@SireWilliamson I need you to give us more logs of NBX. But 502 bad gateway is probably unrelated. The 502 bad gateway is typically sent by reverse proxies such as nginx when they don't manage to connect to the internal server. You error show "http://127.0.0.1:23000/", why 23000? |
Beta Was this translation helpful? Give feedback.
-
So I was right. Thanks for your help though. I hope others, if they encounter this problem, know how to fix it now. |
Beta Was this translation helpful? Give feedback.
So I was right.
Because NBXplorer was not actually running properly, BTCPay never got to the point where it was broadcasting on :23000.
NBXplorer wasn't running correctly, because every time it started it was trying to re-migrate from DBTrie. Since the default is NOT to delete the old DBTrie after migration, the automigrate was getting confused. There should be a flag stating that migration was already completed, the first time it is done, so that if someone tries that option again, it just says, "This was already done." and skips, even if the old DBTrie still exists. OR It should by default delete the old DBTrie once migration is completed.
Thanks for your help though. I hope others, if …