On Thu, Jul 31, 2025 at 10:35:18AM -0700, Otto Kekäläinen wrote: > Hi!
Hi Otto! > I skimmed through https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109499 > quickly and my initial thought here is that Bacula (or any other program) > should not rely on dpkg maintainer scripts to upgrade the database as there > isn't any guarantees about what the initial state is, and if anything fails > it's really hard to restart or recover. Any failures happening during a > dpkg run in general will block the upgrades/installs/uninstalls for the > whole system as apt will refuse to do any new actions until the pending > dpkg package action has completed successfully. When there are failures, it's not bad when this is immediately visible to the administrator. > Instead I would recommend to do the upgrade as part of the systemd/init > service startup sequence. If it fails it's much easier to restart and debug > and the failure will only affect one single service, not the whole OS > package management system. That sounds like a bad idea to me. The postinst will restart the service, which might start the migration in the background. The migration might take a long time. There is likely a recommendation to reboot when the package management system has finished upgrading all packages. The administrator reboots, not being aware that a migration is still running in the background. > Doing an upgrade check and upgrading the > database as part of the startup sequence will also behave correctly if the > user is for example restoring an old database from backups and trying to > start it with a new version of Bacula. How do you restore anything from backups when the database of your backup server is broken? cu Adrian
