[Bug] [podman] Updates is showing, but does not look like it has been done

[LeeNX]

What happened?
This might be a podman corner case, but rather me open up with what I have and collect info as much as possible.

This is post a self-update on my podman host. As can be seen, the dockSentry container is showing v1.32.1, but the webUI is still reporting the old version v1.19.1 at the bottom of the page.

History is showing

Date	Name	Result	Detail
2026-06-28 08:24:53	docksentry	✅	🗓️ 2026-06-07 → 2026-06-27 (selfupdate v1.19.1 → ?)

podman-compose ps

podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.9.3
podman ps -a --filter label=io.podman.compose.project=dockersentry
CONTAINER ID  IMAGE                                 COMMAND     CREATED      STATUS                 PORTS                   NAMES
615b9f13e2ba  ghcr.io/amayer1983/docksentry:latest              2 weeks ago  Up 47 hours (healthy)  0.0.0.0:9090->8080/tcp  docksentry
exit code: 0

Does not look like the container been restarted or re-created?

Let me know if there is any more info I can provide.

logs

podman-compose logs -f
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.9.3
podman logs -f docksentry
Scheduled check triggered at 2026-06-28 09:00
  Skipped (self): docksentry
Checking 4 containers for updates...
  Checking: traefik (registry-1.docker.io/library/traefik:v3.7.5)
  Local:  sha256:e4d98158c01ad752fc1071d..., sha256:e5491c6c7073c18a2fa8ae4...
  Remote: sha256:e4d98158c01ad752fc1071d...
  → Up to date
  Checking: esphome (ghcr.io/esphome/esphome:2026.6.2)
  Local:  sha256:526a75c8d64a0d962a3b088..., sha256:c329d701d864a7c656d6bf7...
  Remote: sha256:526a75c8d64a0d962a3b088...
  → Up to date
  Checking: watchstate (ghcr.io/arabcoders/watchstate:latest)
  Local:  sha256:69de0c1fd519155122f1d2d..., sha256:dae3402dd8bc62bc5d3cd10...
  Remote: sha256:69de0c1fd519155122f1d2d...
  → Up to date
  Checking: dozzle-hub (ghcr.io/amir20/dozzle:latest)
  Local:  sha256:2e14180fa14c195b8e86705..., sha256:e2971b012e7ea1294b6211f...
  Remote: sha256:2e14180fa14c195b8e86705...
  → Up to date
Found 0 updates.

• Docksentry version: v1.19.1 to v1.32.1
• Podman version: 4.9.3
• OS: Ubuntu 24.04
• Deployment: podman-compose

[amayer1983]

Thanks for the thorough report — that is a useful corner case. The new image got pulled, but podman ps shows the container is still the original (2 weeks old, 47h uptime), so the self-update helper that performs the stop/rename/run swap never completed on Podman. That helper runs as a throwaway docksentry_updater container talking to the Docker/Podman socket — and the history → ? placeholder confirms the new version never actually booted to patch it.

To see where it failed:

1. Catch the helper logs. Run /selfupdate again, then immediately:

   podman ps -a | grep updater
   podman logs docksentry_updater
   

   (it is launched with --rm, so grab it quickly; if it is already gone, re-run and catch it.)
2. Which socket is mounted into docksentry? The volumes: line of your compose. The helper currently hardcodes -v /var/run/docker.sock:/var/run/docker.sock; on Podman the working socket is often elsewhere (e.g. /run/podman/podman.sock), so the helper would mount nothing and its docker stop/rename/run would silently no-op — which exactly matches "image pulled, container untouched".

My hunch is #2 (socket path). If so the fix is to have the helper reuse the same socket Docksentry itself uses instead of the hardcoded path. Your answers will confirm it.

[LeeNX]

Mmm, I am going to have to put a little bit of time aside to catch the update process or some way to get these logs.

As a side note, my docker hosts seem to not have a problem and they are using /var/run/docker.sock:/var/run/docker.sock, as for my podman hosts, are using the podman user path, as in /run/user/1002/podman/podman.sock:/var/run/docker.sock. podman-compose would not start up if the sock file did not exist. Just ran a test, where I restarted a container with dockSentry in the WebUI and that worked fine, so I don't think it's the problem with podman interface, unless the restart is not using the sock interface.

[amayer1983]

No need to chase the helper logs anymore — your socket-path note nailed it. 🙌 The self-update helper is a separate throwaway container, and it was launched with a hardcoded -v /var/run/docker.sock:/var/run/docker.sock. On your Docker hosts that matches, so they work. On your Podman hosts the real host socket is /run/user/1002/podman/podman.sock (you map it to /var/run/docker.sock inside docksentry) — but the helper asked the daemon for /var/run/docker.sock on the host, which doesn't exist there, so the helper got an empty socket and its stop/rename/run silently did nothing. That's exactly why the image pulled but the container was never recreated (and why WebUI restart worked — that uses the in-container socket).

Fixed in v1.35.0: the helper now mounts the same host socket docksentry itself uses, resolved from docksentry's own inspect Mounts (so it picks up /run/user/1002/podman/podman.sock automatically; also honours DOCKER_HOST). Once your podman host is on v1.35.0, /selfupdate should actually recreate the container. Please give it a try and confirm.

[LeeNX]

Noice, thanks @amayer1983 . I will have to wait til the next release, to check all works as expected. I believe that will happen in 5min from now ... ;-)

I will keep open til I can confirm.

[LeeNX]

Updating from v1.36.0 to 1.38.1 on my podman host, broke.

leet@cylon:/opt/podman.d/dockersentry$ podman-compose ps
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.9.3
podman ps -a --filter label=io.podman.compose.project=dockersentry
CONTAINER ID  IMAGE                                 COMMAND     CREATED     STATUS                                   PORTS                   NAMES
cf197efd37a7  ghcr.io/amayer1983/docksentry:latest              2 days ago  Exited (0) About a minute ago (healthy)  0.0.0.0:9090->8080/tcp  docksentry_old
exit code: 0
leet@cylon:/opt/podman.d/dockersentry$ podman-compose logs -f
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.9.3
podman logs -f docksentry
Error: no container with name or ID "docksentry" found: no such container
exit code: 125

[amayer1983]

Sorry — that one bit hard. Two parts:

Get your host back up right now (Docksentry is renamed to docksentry_old and stopped):

podman rm -f docksentry 2>/dev/null
podman rename docksentry_old docksentry
podman start docksentry

(or just podman-compose up -d in the stack dir).

What happened: the self-update helper does stop → rename→_old → run new → rm _old. Your stop + rename worked (so the socket fix from v1.35.0 is doing its job now), but the docker run recreate failed on Podman, and the old chain stopped right there — old container renamed away and stopped, no new one, no rollback. That's the brick.

Fixed in v1.38.2: the recreate is now guarded — if docker run fails, it renames _old back and starts it, so Docksentry survives on the previous version instead of dying. A failed self-update becomes a no-op, not a brick.

Still need your help for the root cause — why the Podman docker run fails. Once you're back on v1.38.2, run /selfupdate again (it'll now safely roll back if it fails) and grab the helper's error:

podman logs docksentry_updater

(it's launched with --rm, so catch it quickly — or run podman events & in another shell first). That stderr will tell us which flag Podman rejects, and I'll fix the recreate itself.