Debian Patches
Status for barman/3.19.1-3
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| add-pyproject-toml.patch | Add minimal pyproject.toml to enable PEP517 builds Declares setuptools.build_meta as the build backend so the package is built via PEP517 (producing a .dist-info directory) instead of the legacy setup.py install path (which produces a .egg-info directory). Configuration is still read from setup.py. |
not-needed | vendor | 2026-05-28 | ||
| systemd-receive-wal-integration.patch | Supervise receive-wal processes through systemd When systemd is the running init (/run/systemd/system exists) and the per-server unit can be managed, "barman cron" starts each streaming server's WAL receiver via the dedicated template unit "barman-receive-wal@<server>.service" instead of forking and detaching it with os.setsid(); the same applies to Server.restart_processes() (config-switch/config-update). If the unit cannot be started (systemd is absent, or the unprivileged barman user is not authorised because polkit is not installed) it falls back to forking the receiver as before. The choice has no configuration knob; it is detected at run time. . Under systemd the receiver runs in its own cgroup, supervised and restarted by systemd. The forked fallback, when used, is still a child of the cron oneshot, so barman.service keeps KillMode=process (Debian #1138696) to let it outlive the cron run. . Stopping is detected, never configured: ProcessManager.kill() reads the process cgroup (/proc/<pid>/cgroup) and, if the PID is supervised by a barman-receive-wal@ unit, runs "systemctl stop <unit>" instead of signalling the PID (which systemd would just revive). When no live receiver is found (e.g. the unit is in a Restart= backoff window, where the lock is released and the process is briefly gone) the unit is stopped by its deterministic name as a fallback. This makes "barman receive-wal --stop" and cron's own disable path stop the receiver reliably, with no extra flag and no stored state. ("barman receive-wal --reset" is unchanged: as before, it still requires the receiver to be stopped first.) |
Marco Nenciarini <mnencia@debian.org> | not-needed | 2026-06-04 |
