Bug: runtime error and container stops.

[YanisKyr]

Is this urgent?

No

Host OS

Docker on DSM 7.1

CPU arch

x86_64

VPN service provider

NordVPN

What are you using to run the container

Portainer

What is the version of Gluetun

Running version pr-848 built on 2022-02-20T03:27:48.093Z (commit dcba2bb)

What's the problem 🤔

I think this issue started on 20 Feb when the last update was pulled by Watchtower. Unfortunately I'm not sure how to roll back or troubleshoot this further.

Share your logs

Running version pr-848 built on 2022-02-20T03:27:48.093Z (commit dcba2bb)
🔧 Need help? https://github.com/qdm12/gluetun/discussions/new
🐛 Bug? https://github.com/qdm12/gluetun/issues/new
☕ Discussion? https://github.com/qdm12/gluetun/discussions/new
✨ New feature? https://github.com/qdm12/gluetun/issues/new
💻 Email? quentin.mcgaw@gmail.com
💰 Help me? https://www.paypal.me/qmcgaw https://github.com/sponsors/qdm12
2022/02/22 09:07:18 INFO routing: default route found: interface eth0, gateway 172.17.0.1
2022/02/22 09:07:18 INFO routing: local ethernet link found: eth0
2022/02/22 09:07:18 INFO routing: local ipnet found: 172.17.0.0/16
2022/02/22 09:07:18 INFO firewall: enabling...
2022/02/22 09:07:18 INFO firewall: enabled successfully
2022/02/22 09:07:19 WARN Caught OS signal, shutting down
2022/02/22 09:07:19 INFO storage: merging by most recent 11173 hardcoded servers and 11173 servers read from /gluetun/servers.json
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x711a33]
goroutine 21 [running]:
	github.com/qdm12/gluetun/internal/configuration/settings/openvpn.go:112 +0x293
github.com/qdm12/gluetun/internal/configuration/settings.(*VPN).validate(_, {0x1, {0x4, 0x614c8660, {0xc00029e000, 0xb8, 0xb8}}, {0x1, 0x61f2977a, {0xc000110000, ...}}, ...})
	github.com/qdm12/gluetun/internal/configuration/settings/vpn.go:38 +0x1f8
github.com/qdm12/gluetun/internal/configuration/settings.(*Settings).Validate.func1()
	github.com/qdm12/gluetun/internal/configuration/settings/settings.go:45 +0x5f
github.com/qdm12/gluetun/internal/configuration/settings.(*Settings).Validate(_, {0x1, {0x4, 0x614c8660, {0xc00029e000, 0xb8, 0xb8}}, {0x1, 0x61f2977a, {0xc000110000, ...}}, ...})
	github.com/qdm12/gluetun/internal/configuration/settings/settings.go:50 +0x990
main._main({0xd2ad98, 0xc00044d480}, {{0xd17408, 0x6}, {0xd176e8, 0x7}, {0xd19220, 0x18}}, {0xc00008a1f0, 0x1, ...}, ...)
	./main.go:226 +0xca5
main.main.func1()
	./main.go:87 +0x150
created by main.main
	./main.go:86 +0x649

Share your configuration

version: "3"
services:
    gluetun:
        cap_add:
            - NET_ADMIN
        container_name: gluetun
        image: qmcgaw/gluetun:latest
        network_mode: bridge
        environment:
            - VPN_SERVICE_PROVIDER=nordvpn
            - VPN_TYPE=openvpn
            - OPENVPN_PROTOCOL=udp
            - OPENVPN_USER=***
            - OPENVPN_PASSWORD=***
            - UPDATE_PERIOD=24h
            - SERVER_REGIONS=Netherlands
            - TZ=Europe/London
            - PUID=***
            - PGID=***
        devices:
            - /dev/net/tun:/dev/net/tun
        privileged: true
        volumes:
            - /volume1/docker/gluetun:/config
        restart: unless-stopped

[qdm12]

See #855 just repull latest and that should fix it.

docker pull qmcgaw/gluetun

[YanisKyr]

Thanks for the quick reply.

Shall I stop using the latest tag altogether?

[qdm12]

First off, the bug you experienced was due to the build pipeline messing up, not the actual latest branch. What happened was that it pushed a test image (for pr #848) as the latest image and obviously that other branch PR wasn't meant to be stable. So even if there would be a stable rolling tag, you would had encountered a similar problem. I'm trying my best at having a stable latest image and I usually take only a 1-4 hours to fix it when it rarely breaks

Now it depends:

• if you want to have the latest features/fixes and help me fix niche bugs (not critical like this one) then keep on using the latest image. That's why I don't point latest to a the latest stable release otherwise I have no way to know if everything is functional before making it a new release which would end up unstable too. You can always roll back on a previous release image if latest breaks.
• you can use a release tag like :v3.27.0 which won't change, this should be stable too.
• Soon you should be able to use :v3 which will point to the latest v3.x.x release. That's stable but also allows updates.

I'm working on that last point, subscribe to the other issue mentioned to know when you can do it 😉

[dsm1212]

Cool, I don't mind being on latest, but I'll stick with the older version until there is a new build. Question though, on the older version I can't see that an ipv6 firewall is set up. Is that what the commit I pointed to was fixing? Thanks!!

[qdm12]

but I'll stick with the older version until there is a new build

There is a new latest build pretty much every 1/3 days.
You can now also use image v3 which will point to the last stable release (v3.28.0 for now).

on the older version I can't see that an ipv6 firewall is set up.

It only sets up the ipv6 firewall if IPv6 is supported, and you need to enable it in your container. By default it's disabled by Docker. The last commit should only fix the firewall when nft is the only available firewall interface and there is no 'older' iptables kernel module.