Your message dated Tue, 10 Mar 2026 15:16:02 +0100
with message-id <[email protected]>
and subject line Re: Bug#1103307: rsyslog-pgsql fails to configure after
debconf database is lost
has caused the Debian Bug report #1103307,
regarding rsyslog-pgsql fails to configure after debconf database is lost
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1103307: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103307
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Am 22.04.25 um 20:17 schrieb Paul Gevers:
Hi,
On 22-04-2025 17:50, Kim-Alexander Brodowski wrote:
Unfortunately, I can't. No question is ever asked, not even when
reinstalling. I can't see any obvious calls to debconf's INPUT either.
Can you check the content of /etc/dbconfig-common/rsyslog-pgsql.conf ? I
assume it has (or something similar, I don't have an example at hand):
dbc_install=false
As dbconfig-common really is fundamental in debconf-is-not-a-registry,
it does store the answers by itself in a configuration file. Reading
through the code, I think that if you opted out of dbconfig-common help
during the first time (maybe by another bug). However, once you opt out
of dbconfig-common support, that's honored. I have a very old bug about
that open. The full bug is a long read if you go through it, but the
above is explained in more detail in
https://bugs.debian.org/825735#62 (the paragraph that starts with
"Interestingly").
Does it help to change that dbc_install=false to dbc_install=true and
run dpkg-reconfigure again?
Paul
We haven't heard back, so I'm closing this bug report.
Regards
Michael
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
