[pkg-bacula-devel] Bug#923444: Bug#923444: bacula: autopkgtest regressed in buster

[Sven Hartge]

Um 12:44 Uhr am 28.02.19 schrieb Sven Hartge:

> I can reproduce the problem by running autopkgtest locally. It seems the 
> postgresql daemon not starting is the main problem. This of course 
> causes the director then to fail as well during setup.

I don't think the bug is inside Bacula but in a different package or
system.

The main problem is postgresql here.

It starts too late inside the autopkgtest environment, after
bacula-common-pgsql has been installed and (tried to be) configured. Look
at the order in which postgresql-common, bacula-director-pgsql and
postgresql-11 are configured here:

[......]
Setting up bacula-client (9.4.2-2) ...
Setting up postgresql-client (11+199) ...
Setting up dbconfig-pgsql (2.0.11) ...
Setting up bacula-common-pgsql (9.4.2-2) ...
Setting up libunbound8:amd64 (1.9.0-2) ...
Setting up ssl-cert (1.0.39) ...
Setting up postgresql-common (199) ...
ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Adding user postgres to group ssl-cert

Creating config file /etc/postgresql-common/createcluster.conf with new version
Building PostgreSQL dictionaries from installed myspell/hunspell packages...
Removing obsolete dictionary files:
Created symlink /etc/systemd/system/multi-user.target.wants/postgresql.service → /lib/systemd/system/postgresql.service.
Setting up libxslt1.1:amd64 (1.1.32-2) ...
Setting up bacula-bscan (9.4.2-2) ...
Setting up libgnutls-dane0:amd64 (3.6.6-2) ...
Setting up bacula-director-pgsql (9.4.2-2) ...
dbconfig-common: writing config to /etc/dbconfig-common/bacula-director-pgsql.conf

Creating config file /etc/dbconfig-common/bacula-director-pgsql.conf with new version
unable to connect to postgresql server.
error encountered creating user:
psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

dbconfig-common: bacula-director-pgsql configure: noninteractive fail.
dbconfig-common: bacula-director-pgsql configure: ignoring errors from here forwards
populating database via administrative sql...  done.
populating database via sql...  done.
dbconfig-common: flushing administrative password
Setting up postgresql-11 (11.2-1) ...
Creating new PostgreSQL cluster 11/main ...
/usr/lib/postgresql/11/bin/initdb -D /var/lib/postgresql/11/main --auth-local peer --auth-host md5
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
[......]

After this, everything else falls apart, because neither does the bacula
user nor the database exist.

Why can't bacula-director-pgsql depent on postgressl-server? Because we
support a remote database.

--> Further analysis:

Looking at the older autopkgtest logs, one can see that up 2019-02-23
01:38:30 UTC the package "postgresql-11" was installed and configured
before bacula-director-pgsql.

Then, on 2019-02-25 02:18:41 UTC something changed outside of the bacula
packages and the order in which those two packages get configured
reversed, causing the problems.

Grüße,
Sven.