Package: rsyslog-pgsql
Version: 8.2302.0-1+deb12u1
Severity: normal
Dear Maintainer,
Background:
We currently operate over 10,000 machines utilizing rsyslog-pgsql. We
have been noticing for some time that rsyslog-pgsql does occasionally
not install properly. Unfortunately, I cannot pinpoint the exact reason
in each and every case, since recovery of the affected systems often
takes precedence over bug analysis. This is a long way of saying that we
noticed that package configuration in particular seems to be
occasionally flakey.
In one case today, an internal test machine was affected and I do know
why and how that caused problems for rsyslog-pgsql. Due to an unrelated
human error, the machine had to be restored from backup.
Problem:
As per Filesystem Hierarchy Standard (FHS), we do not include /var/cache
in our backups, since all data in /var/cache should be expendable. This
means that /var/cache/debconf/config.dat, debconfs config database, is
also not included in backups.
The packages I've looked at outside of rsyslog-pgsql, e.g. wireshark or
tzdata, appear to gracefully handle this loss. rsyslog-pgsql does not.
Deleting the debconf config database after the initial installation of
rsyslog-pgsql appears to break the package.
kim.iserv.dev ~ # LC_ALL=C dpkg --configure -a
Setting up rsyslog-pgsql (8.2302.0-1+deb12u1) ...
dbconfig-common: writing config to
/etc/dbconfig-common/rsyslog-pgsql.conf
Not replacing deleted config file /etc/rsyslog.d/pgsql.conf
dbconfig-common: flushing administrative password
dpkg: error processing package rsyslog-pgsql (--configure):
installed rsyslog-pgsql package post-installation script subprocess
returned error exit status 10
Errors were encountered while processing:
rsyslog-pgsql
This is not the only case that can lead to rsyslog-pgsql breaking. One
of the automated workarounds we have pushed to machines is to run:
echo "REGISTER rsyslog-pgsql/internal/reconfiguring boolean" |
debconf-communicate
Whenever this does not succeed:
echo "GET rsyslog-pgsql/internal/reconfiguring" | debconf-communicate
I believe this workaround became necessary after the Debian upgrade from
Buster to Bullseye, but don't quote me on that.
Expected behaviour:
rsyslog-pgsql should handle a (partial) loss of debconf settings
gracefully, e.g. ask interactive questions etc., but not break package
configuration.
The problem is particularly bad, since "normal" error recovery
procedures (purging the package, reinstallation, ...) do not appear to
resolve the problem.
Workaround:
If you are affected by the problem, you can restore entries in
/var/cache/debconf/config.dat from a working system. It's a simple text
file. Make sure to create a backup.
As with every bug report I submit, I'd like to take the opportunity to
extend our gratitude for the work done by the Debian developers and
maintainers, as well as the upstream developers. We greatly appreciate
the time and effort you put into these projects.
Best regards,
Kim-Alexander Brodowski
IServ GmbH
-- System Information:
Debian Release: 12.10
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-33-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages rsyslog-pgsql depends on:
ii dbconfig-common 2.0.24
ii debconf [debconf-2.0] 1.5.82
ii libc6 2.36-9+deb12u10
ii libpq5 15.12-0+deb12u2
ii rsyslog 8.2302.0-1+deb12u1
ii ucf 3.0043+nmu1+deb12u1
Versions of packages rsyslog-pgsql recommends:
ii postgresql-client-15 [postgresql-client] 15.12-0+deb12u2
Versions of packages rsyslog-pgsql suggests:
ii postgresql 15+248
-- debconf information excluded
