The postgresql module has a postStart section that waits for a database
to accept connections before continuing. However, this assumes various
properties about the database - specifically the database user
and (implicitly) the database name. This means that for old
installations, this command fails because there is no 'postgres' user,
and the service never starts.
While 7deff39 does create the 'postgres' user, a better solution is to
use `pg_isready`, who's sole purpose is to check if the database is
accepting connections. This has no dependency on users, so should be
more robust.
Old PostgreSQL installations were created using the 'root' database
user. In this case, we need to create a new 'postgres' account, as we
now assume that this is the superuser account.
Unfortunately, these machines will be left with a 'root' user as
well (which will have ownership of some databases). While PostgreSQL
does let you rename superuser accounts, you can only do that when you
are connected as a *different* database user. Thus we'd have to create a
special superuser account to do the renaming. As we default to using
ident authentication, we would have to create a system level user to do
this. This all feels rather complex, so I'm currently opting to keep the
'root' user on these old machines.
as per postgresql manual, interactions with psql should be carried
out with the postgresql system user and postgresql db user by default.
ensure it happens in postStart.
This reverts commit f7d5e83abb. It
breaks the Firefox and Xfce tests:
in job ‘tests.firefox.x86_64-linux’:
cannot coerce a boolean to a string
in job ‘tests.xfce.x86_64-linux’:
infinite recursion encountered
Latest update to udisks in 344f2e65 broke it for me. Fix it by doing the
following:
- Add udisks.service to /etc/systemd/system (via systemd.packages)
- Fix path to udisks-daemon in udisks.service (libexec/ instead of lib/)
- Make dhcp work, use dhcpcd without udev in container
- Make login shell work, patch getty to not wait for /dev/tty0
- Make ssh work, sshd/pam do not start session
According to the MySQL manual, this is a perfectly legal way of
shutting down the server. The shutdown logs also looks fine:
systemd[1]: Stopping MySQL Server...
mysqld[5114]: 140319 8:36:12 [Note] /nix/store/sc26mz82k97mbpx3d1abzn3rrbd155ws-mariadb-10.0.8/bin/mysqld: Normal shutdown
mysqld[5114]: 140319 8:36:12 [Note] Event Scheduler: Purging the queue. 0 events
mysqld[5114]: 140319 8:36:12 [Note] InnoDB: FTS optimize thread exiting.
mysqld[5114]: 140319 8:36:12 [Note] InnoDB: Starting shutdown...
mysqld[5114]: 140319 8:36:14 [Note] InnoDB: Shutdown completed; log sequence number 1619078
mysqld[5114]: 140319 8:36:14 [Note] /nix/store/sc26mz82k97mbpx3d1abzn3rrbd155ws-mariadb-10.0.8/bin/mysqld: Shutdown complete
systemd[1]: Stopped MySQL Server.
