sigterm not being caught on reboot

[darmach]

Is there a pinned issue for this?

• I have read the pinned issues and could not find my issue

Is there an existing or similar issue/discussion for this?

• I have searched the existing issues
• I have searched the existing discussions

Is there any comment in the documentation for this?

• I have read the documentation, especially the FAQ and Troubleshooting parts

Is this related to a provider?

• I have checked the provider repo for issues
• My issue is NOT related to a provider

Are you using the latest release?

• I am using the latest release

Have you tried using the dev branch latest?

• I have tried using dev branch

Docker run config used

services:
    transmission-openvpn:
        container_name: transmission-openvpn
        restart: always
        cap_add:
            - NET_ADMIN
        volumes:
            - './shares:/shares'
            - './config:/config'
            - './openvpn:/etc/openvpn/custom'
        environment:
            - TZ=Europe/Berlin
            - PUID=982
            - PGID=1001
            - OPENVPN_PROVIDER=vpnprovider
            - OPENVPN_USERNAME=redacted
            - OPENVPN_PASSWORD=redacted
            - OPENVPN_CONFIG=poland
            - LOCAL_NETWORK=192.168.0.0/22,10.0.0.0/22
            - TRANSMISSION_DOWNLOAD_DIR=/shares
            - TRANSMISSION_RPC_AUTHENTICATION_REQUIRED=true
            - TRANSMISSION_RPC_USERNAME=redacted
            - TRANSMISSION_RPC_PASSWORD=redacted
            - TRANSMISSION_RPC_WHITELIST=127.0.0.1,192.168.1.2
            - TRANSMISSION_RPC_ENABLED=true
        logging:
            driver: json-file
            options:
                max-size: 10m
        ports:
            - '9091:9091'
        image: haugene/transmission-openvpn

Current Behavior

This is a reopen of an issue created by @lucserre user: #2246 as the issue still persist and causes reboot of my hypervisor to take about 5 minutes longer - impacting all the other services deployed there, i.e. CCTV

Everything works, until I try to reboot. It
hangs at shutdown for several (5+) minutes.
Seems not to be listening to the SIGTERM or SIGKILL signals being sent to it.
Using Debian 11.
When I reboot or shutdown the system, while the docker container is running:
I get this first one for about 3-4 minutes
systemd-shutdown[1]: Waiting for process: containerd-shim, dumb-init
and then this one for an other 3-4 minutes.
systemd-shutdown[1]: Waiting for process: dumb-init

Expected Behavior

SIGTERM signal to gracefully terminate the container

How have you tried to solve the problem?

updated to latest version
tried on new OS (new debian11 vm)

In my case - it's Ubuntu Noble

Log output

systemd-shutdown[1]: Waiting for process: containerd-shim, dumb-init
and then this one for an other 3-4 minutes.
systemd-shutdown[1]: Waiting for process: dumb-init

HW/SW Environment

- OS: Ubuntu 24.04 Noble
- Docker: Docker version 28.0.4, build b8034c0

Anything else?

Reopen of #2246
Impact - long hypervisor reboots, causing wider service unavailability

[Silversurfer79]

Think its related to this, I think the development has stopped. My issue seems to be about 4 years now.
#2130

[darmach]

@Silversurfer79 I think I had read somewhere that @haugene is back supporting the project, possibly some discussion or other issue :)

[haugene]

Hey guys 👋 Yes, you probably did read that in some discussion or issue @darmach. I had high hopes, but didn't really get going.
I see two issues are linked here. The #2246 issue is the same as this. Let's follow up on that here.

But the issue you're linking to @Silversurfer79 seems to be a bit different. Where this issue is that the container takes a long time to die when you actively try to kill it the other one seems to be that the container dies when you don't want it to. There might be overlap here, but let's treat them as separate issues for now as I think they might be unrelated.

[haugene]

I've been trying to research this issue a bit @darmach and I thought I saw a plausible explanation, but no... I don't understand what's going on.

When the container starts it uses dumb-init as PID 1 and the openvpn/start.sh script will exec and let openvpn replace the start.sh bash process. That way the dumb-init can signal OpenVPN directly.

dumb-init is very small and stable. I don't think the problem lies there. Also, OpenVPN should be able to handle a SIGTERM. When OpenVPN gets the signal it should call tunnelDown.sh which in turn calls transmission/stop.sh where we loop SIGTERM 5 times (by default) and then do a SIGKILL.

So I'm a bit curious where this goes wrong. Because this isn't that much of signal propagation thing that I first thought. It's a call-order, at least after OpenVPN does it thing.

Are you still able to reproduce it? Can you try to stop the container, and observe it hanging, and give some more logs? I see the Waiting for process: dumb-init has been posted, but I need to see more of the full logs. Docker will wait for dumb-init, but dumb-init is probably waiting for OpenVPN to exit, and the question is... what is OpenVPN waiting for?

Just out of curiosity. Even though I said I don't think this is about signal propagation, you can try to start the container with env var DUMB_INIT_SETSID=0 and see if that makes a difference.

Curious to hear what you find. Have you also tried to pull and run the latest :dev tag? There's probably some OpenVPN and other library updates - who knows - it might resolve itself? 🤞 🙈