Hi!

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.

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. 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.

<div dir="auto">Hi!<div dir="auto"><br></div><div dir="auto">I skimmed through <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109499">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109499</a> 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&#39;t any guarantees about what the initial state is, and if anything fails it&#39;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. </div><div dir="auto"><br></div><div dir="auto">
Instead I would recommend to do the upgrade as part of the systemd/init service startup sequence. If it fails it&#39;s much easier to restart and debug and the failure will only affect one single service, not the whole OS package management system. 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.</div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

When there are failures, it's not bad when this is immediately visible
to the administrator.

If the server is not fully dedicated to just running Bacula, then
preventing dpkg/apt from doing anything is a bit overkill just for the
sake of notifying the user.

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.

There are many ways to communicate things to the system admin, but if
they fail, the service would still restart the database schema
migration etc immediately after restart when the service file would
try to start Bacula and notice that upgrade wasn't completed.

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?

We are now talking about Bacula's own database schema, right? For
example, if the hardware was broken and the sysadmin is installing
Trixie on a new host and installs the latest Bacula but takes the
Bacula database from the old Bookworm server, the Bacula schema would
never migrate if it only happens when triggered by dpkg. If it is part
of the service startup, it would always do the upgrade of the database
scheme when Bacula starts and it detects the stuff on the disk is of
an older format than what the running binary wants to use.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)