[BUG] Stale lockfile after ungraceful shutdown causes silent crash loop on container restart

[osamarao]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

After an ungraceful host shutdown (power loss, forced reboot, kernel panic), /config/qBittorrent/lockfile is left behind on the persistent volume.

On the next container start, qBittorrent detects the lockfile, assumes another instance is already running, and immediately self-terminates repeatedly, ~once per second.

The web UI never becomes reachable. docker logs shows only the LSIO init banner and stops; there is no error message. The container itself reports Up the whole time because s6 is healthy.

Expected Behavior

The container should start normally and the web UI should be reachable after an ungraceful shutdown, the same as after a clean one.

Steps To Reproduce

1. Run the container with a persistent /config volume.
2. Hard-kill the host while qBittorrent is running (power cut, forced reboot, or kill -9 on the container process) — anything bypassing graceful shutdown.
3. Start the container again.
4. Web UI is unreachable. docker logs shows only the LSIO banner with no further output.

To confirm:

docker exec qbittorrent cat /config/qBittorrent/logs/qbittorrent.log will show a rapid loop of:
(N) - qBittorrent vX.X.X started. Process ID: XXXX
(N) - qBittorrent termination initiated
(N) - qBittorrent is now ready to exit

Root cause: Qt's QLockFile stores hostname + PID in the lockfile. After a reboot, Linux reuses PIDs. The old qBittorrent PID is typically reused by a system process before qBittorrent starts. Qt sees "PID X is running" → treats the lock as live → qBittorrent self-terminates. This is a known QLockFile limitation and cannot be reliably fixed upstream without switching to a socket-based lock.

Suggested fix — one line in the s6 run script before exec qbittorrent-nox:
rm -f /config/qBittorrent/lockfile
This is safe: the lockfile's only purpose is to block a second simultaneous instance, which the container model already prevents.

Environment

- OS: Unraid 6.12.85
  - How docker service was installed: Built into Unraid (managed via Compose Manager plugin)

CPU architecture

x86-64

Docker creation

services:
    gluetun:
      image: qmcgaw/gluetun
      ports:
        - 8888:8888
        - 6881:6881
        - 6881:6881/udp

    qbittorrent:
      image: lscr.io/linuxserver/qbittorrent
      network_mode: service:gluetun
      environment:
        - PUID=99
        - PGID=100
        - TZ=US/Central
        - WEBUI_PORT=8888
      volumes:
        - /mnt/user/appdata/qbittorrent:/config
        - /mnt/user/data/torrents:/data/torrents

Container logs

(Logs captured during the crash loop — container had been "Up" for 15+ minutes with no web UI)

  [migrations] started
  [migrations] no migrations found

        ██╗     ███████╗██╗ ██████╗
        ...linuxserver.io banner...

  Linuxserver.io version: 5.2.1_v2.0.12-ls459
  Build-date: 2026-05-26T04:47:45+00:00

  [custom-init] No custom files found, skipping...
  (output ends here — no web UI binding, no error)

  /config/qBittorrent/logs/qbittorrent.log at time of incident:
  (N) 2026-05-26T12:13:40 - qBittorrent v5.2.1 started. Process ID: 4967
  (N) 2026-05-26T12:13:40 - Using config directory: /config/qBittorrent
  (N) 2026-05-26T12:13:40 - qBittorrent termination initiated
  (N) 2026-05-26T12:13:40 - qBittorrent is now ready to exit
  (N) 2026-05-26T12:13:41 - qBittorrent v5.2.1 started. Process ID: 4975
  (N) 2026-05-26T12:13:41 - Using config directory: /config/qBittorrent
  (N) 2026-05-26T12:13:42 - qBittorrent termination initiated
  (N) 2026-05-26T12:13:42 - qBittorrent is now ready to exit
  ... (repeating every ~1 second)

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[j0nnymoe]

Known issue: #432

Can use stop_grace_period: "10s" in your compose (make it longer than 10s) to extend the shutdown time which should solve the issue.

For the unsafe shutdown situation, Just mentioned it internally and we'll discuss how we want to handle this. Though we don't like adding stuff like this to containers where this would also happen on bare metal installs too.

[scarfacestrawberry]

This recent issue seems to be more related to the qbitorrent issue qbittorrent/qBittorrent#24164 which is probably why i just ran into this issue. Though i feel like the correct solution here should be the lockfile being in volatile storage...