Bug#1103307: rsyslog-pgsql fails to configure after debconf database is lost
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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1103307: rsyslog-pgsql fails to configure after debconf database is lost
Am 17.04.25 um 21:37 schrieb Paul Gevers: Hi Michael, Thanks for reaching out. It's been a long time since I looked at dbconfig-common (and I'm not the author), so things are extremely rusty. On 17-04-2025 20:28, Michael Biebl wrote: 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 Are you sure that rsyslog-pgsql can handle an absent config file? ^^ If /etc/rsyslog.d/pgsql.conf is missing, rsyslog should just (re)start without the pgsql module being loaded, i.e. this functionality would simply be absent. Remember that debian policy says that package have to respect the removal of a configuration file by the sys-admin, so dbconfig-common does that and it seems that it registered the file with ucf earlier and now thinks that it was removed. dbconfig-common: flushing administrative password Because it seems like dbconfig-common exited gracefully here. So, I'm wondering if the failure happens during dbconfig-common or afterwards. Maybe you can try what happens if you install rsyslog-pgsql and opt-out of dbconfig-common help (I recall that's the first question). It would indeed be good to see at which step exactly the postinst is failing. Kim-Alexander, can you add a "set -x" right at the top to the scripts in /var/lib/dpkg/info/rsyslog-pgsql.p* OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1103307: rsyslog-pgsql fails to configure after debconf database is lost
Hi Michael, Thanks for reaching out. It's been a long time since I looked at dbconfig-common (and I'm not the author), so things are extremely rusty. On 17-04-2025 20:28, Michael Biebl wrote: 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 Are you sure that rsyslog-pgsql can handle an absent config file? ^^ Remember that debian policy says that package have to respect the removal of a configuration file by the sys-admin, so dbconfig-common does that and it seems that it registered the file with ucf earlier and now thinks that it was removed. dbconfig-common: flushing administrative password Because it seems like dbconfig-common exited gracefully here. So, I'm wondering if the failure happens during dbconfig-common or afterwards. Maybe you can try what happens if you install rsyslog-pgsql and opt-out of dbconfig-common help (I recall that's the first question). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1103307: rsyslog-pgsql fails to configure after debconf database is lost
[Looping in Paul as maintainer of dbconfig-common] Thanks for the detailed bug report. rsyslog-pgsql uses the dbconfig-common framework [1] (which in turn uses debconf internally). So I think it would be up to dbconfig-common to deal with a missing /var/cache/debconf more gracefully. I fear there is not a lot I can do about that in rsyslog(-pgsql) Regards, Michael [1] https://tracker.debian.org/pkg/dbconfig-common Am 16.04.25 um 12:33 schrieb Kim-Alexander Brodowski: 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 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1103307: rsyslog-pgsql fails to configure after debconf database is lost
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