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.
