I discovered this issue while debugging why the PostgreSQL service would not start in my Docker container using systemctl.py
.
The service definition specifies that the startup script should be run as user postgres
who exists in the container and has the home directory /var/lib/pgsql.
The startup script (/usr/lib/postgresql-init) apparently expects to be run as user postgres
and, at one point, does the following:
A few lines later, it attempts to initialise the DB (if that hasn't been done before) sending stdout to a file named initlog, in the local working directory.
That all works fine, when the script is run by regular systemd
, but systemctl.py
apparently sets up the environment differently, so that ~
does not expand to the postgres
user's home, but rather to /root.
This leads to the following errors being logged by the startup script:
/usr/lib/postgresql-init: line 42: cd: /root: Permission denied
Initializing PostgreSQL 9.6.9 at location /var/lib/pgsql/data
/usr/lib/postgresql-init: line 52: initlog: Permission denied
Initialisation failed. See //initlog .
… and lets the initialisation (and thus the service start) fail.
I was able to work around this issue, by putting a drop-in unit file into /usr/lib/systemd/system/postgresql.service.d that explicitly sets
[Service]
Environment="HOME=/var/lib/pgsql"
… but I really consider this a workaround, rather than a fix.
Ideally, when systemctl.py
runs a shell script as some user, the tilde character ~
should expand to that users home directory (as specified in /etc/passwd) if used within the script. If only, because that seems to be the way systemd
does it and there's at least one startup script out there that relies on this behaviour.