LERD v1.19.0 incompatibility with Podman 4.9.3 (Ubuntu 24.04)

[gmartinlabelgrup]

Hi, I’ve been using LERD for around one month now. I’m used to working directly with services on Ubuntu, but we decided to use LERD because some of my coworkers are not familiar with Linux environments.

Today I noticed an issue while updating to 1.19.0. I’m currently running Ubuntu 24, and I’m not sure when I’ll be able to upgrade to Ubuntu 26.

From what I understand, the issue should be resolved in Ubuntu 26, but some backward compatibility would be appreciated.

Here’s the output from Claude about the problem:

---

LERD v1.19.0 refactored its service management by moving all built-in services (MySQL, Redis, PostgreSQL, Mailpit, Meilisearch, RustFS) from hardcoded Go code into YAML presets. As part of
this, the generated Podman quadlet files (.container) now include a StopTimeout=5 key in the [Container] section to give containers a 5-second graceful shutdown window.

However, this key is only supported in Podman 5.0+. Ubuntu 24.04 ships Podman 4.9.3, which does not recognize StopTimeout in the [Container] section of a quadlet file. When systemd's
quadlet generator encounters an unsupported key, it aborts with exit code 1 and generates no service units at all — so lerd-mysql.service, lerd-redis.service, etc. simply never exist from
systemd's perspective.

The compounding issue is that LERD regenerates quadlet files before every service operation (start, stop, restart, reinstall), so manually removing StopTimeout from the files is
immediately overwritten, making a direct fix impossible without either patching the binary or updating Podman.

Root cause in one line: LERD v1.19.0 requires Podman ≥ 5.0; Ubuntu 24.04 provides Podman 4.9.3.

Fix applied: Downgraded to LERD v1.18.1, the last release before StopTimeout was introduced.

Recommended upstream fix: The LERD team should either guard the StopTimeout key behind a Podman version check, or move it to the [Service] section as TimeoutStopSec, which is a standard
systemd key supported by all Podman versions that support quadlets.

---

[geodro]

Thanks for the detailed writeup, your diagnosis was spot on. StopTimeout in [Container] really did land in Podman 5.0, and 4.9.3 quadlet generation aborts entirely when it sees the key, which is the worst possible failure mode since you get zero service units instead of a clear error.

Fix is up in #302. I went with PodmanArgs=--stop-timeout=5 as the fallback on Podman 4.x rather than TimeoutStopSec=, since those mean different things, TimeoutStopSec is systemd's deadline before it SIGKILLs podman itself, which can leave containers dangling, whereas PodmanArgs threads the same --stop-timeout=5 through to the underlying podman run, matching what the StopTimeout key does on 5.0+. Lerd probes podman --version once at startup and picks the right form per host.

Until the fix is released, v1.18.1 is the right workaround as you found. I'll cut a patch release once the PR merges.

[geodro]

Quick follow-up, v1.19.1 is out and includes everything that came up in this thread. The Podman 4.x StopTimeout fallback to PodmanArgs is in, the netavark <1.11 bug on Ubuntu 24.04 is dodged by passing --dns at network create time instead of relying on a post-create network update --dns-add, and the dashboard no longer goes green for a service whose unit was rejected by the quadlet generator. lerd update should pull it in cleanly. If you get a chance to confirm the install works end to end that would be great, and if it all checks out a star on the repo would really help, otherwise let me know what's still broken and I'll dig in.

[gmartinlabelgrup]

The issue present in version 1.19.0 has been resolved in 1.19.1.

Thank you very much for the quick and effective fix.