Closed tsjk closed 1 month ago
I wonder if this happens when the downloaded json is strange. Perhaps we need a validation of that then json actually contains nodes?
diff --git a/protonwire b/protonwire
index 22b4a33..3d569a9 100755
--- a/protonwire
+++ b/protonwire
@@ -852,7 +852,7 @@ function protonvpn_fetch_metadata() {
# Save to a backup file as download can fail or be corrupted
if [[ $curl_rc == "0" ]]; then
# Ensure file is json formatted and valid
- if jq --exit-status '.Nodes' "${__PROTONWIRE_SRV_INFO_FILE}.bak" >/dev/null 2>&1; then
+ if [[ $(jq '.Nodes | length' "${__PROTONWIRE_SRV_INFO_FILE}.bak" 2> /dev/null) -gt 0 ]]; then
if mv --force "${__PROTONWIRE_SRV_INFO_FILE}.bak" "${__PROTONWIRE_SRV_INFO_FILE}"; then
log_success "Successfully refreshed server metadata"
But I'm just guessing here. Gonna try with that on my next restart of the container.
Version
7.5.0
Credential and Server Validation
nl-free-127.protonvpn.net
or server name likeNL#1
) as mentioned in the docs.System Architecture
x86_64
Kernel Version
6.1.0-18-amd64
Running on a NAS?
No
Runtime
podman
Version of Runtime
My configuration
Whitelisting API endpoints
I am not using ad-blocking DNS server or gateway
Troubleshooting & Runtime
Container/Pod/systemd log output with DEBUG=1 or
--debug
flagAny additional info
The error happens now and then. This time it happened when I started the container, and as I recently updated my fork to the latest version, I thought I'd give this additional love by reporting a bug. The error makes the script die, and in the normal setup this kills the container. On my system, this container dying is not acceptable, which is one reason for me having forked the project and made some changes. As you can see, it does get going after a while. So, I wonder whether the error could be handled in the protonwire script, so that it doesn't crash. Here are my logs (without debug, but if you really need that I'll try to reproduce it with - but it doesn't happen on demand...):
Code of Conduct & PII Redaction