The script stops at: invoke-rc.d postgresql start $VERSION #
systemd: argument ignored, starts all versions
This is the last step in the configure_version() function. Is this
really necessary when you use systemctl? Can I comment it safely just to
finish the configuration?
The server has already started a few times so I am sure that postgresql
restarts. Here is information on the postgresql service:
root:~# systemctl status postgresql
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
Active: active (exited) since Fri 2017-08-25 08:08:22 CEST; 2 days ago
Main PID: 1269 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/postgresql.service
Aug 25 08:08:22 jessie systemd[1]: Started PostgreSQL RDBMS.
root:~#
Op 23-08-17 om 19:13 schreef Greg Wooledge:
On Wed, Aug 23, 2017 at 11:28:14AM -0400, Cindy-Sue Causey wrote:
On 8/23/17, Marco DE BOOIJ <marco.maill...@debooy.eu> wrote:
root:~# dpkg --configure postgresql-9.6
Setting up postgresql-9.6 (9.6.4-1.pgdg80+1) ...
dpkg: error processing package postgresql-9.6 (--configure):
subprocess installed post-installation script returned error exit
status 102
Errors were encountered while processing:
postgresql-9.6
A search attempt on the Net landed me the possibility that I'm thinking of:
dpkg --configure -a
Yes, that's probably the first thing to try. But if that fails (again),
then the problem appears to be in the postinst script itself, or more
precisely whatever command the postinst script executes.
I don't have a stretch box with postgresql-9.6 installed at the moment,
but looking at a jessie box with -9.4, the postinst is simply this:
=============================================================
#!/bin/sh
set -e
VERSION=9.4
if [ "$1" = configure ]; then
. /usr/share/postgresql-common/maintscripts-functions
configure_version $VERSION "$2"
fi
=============================================================
Following the trail, the configure_version function is defined in
/usr/share/postgresql-common/maintscripts-functions and looks like:
=============================================================
configure_version() {
VERSION="$1"
# Create a main cluster for given version ($1) if no cluster already exists
# for that version and we are installing from scratch.
[ "$VERSION" ] || { echo "Error: configure_version: need version parameter"
>&2; exit 1; }
if [ ! -d "/etc/postgresql/$VERSION" ] || [ -z "$(ls
/etc/postgresql/$VERSION)" ] || \
[ -z "$(ls /etc/postgresql/$VERSION/*/postgresql.conf 2>/dev/null)" ];
then
# skip creating the main cluster when this is not the first install, or
# when explicitely disabled ($create is 1/0/"")
create=$(perl -I/usr/share/postgresql-common -mPgCommon -e 'print
PgCommon::config_bool(PgCommon::get_conf_value 0, 0, "createcluster.conf",
"create_main_cluster")')
if [ -z "$2" ] && [ "$create" != "0" ]; then
set_system_locale
/usr/bin/pg_createcluster -u postgres $VERSION main ||
echo "Error: could not create default cluster. Please create
it manually with
pg_createcluster $VERSION main --start
or a similar command (see 'man pg_createcluster')." >&2
fi
fi
_link_manpages "$VERSION" postmaster.1.gz "postgresql-$1"
"postgresql-contrib-$1"
if [ -x /etc/init.d/postgresql ] && [ ! -x /etc/init.d/postgresql-$VERSION
]; then
if [ -x "`which invoke-rc.d 2>/dev/null`" ]; then
invoke-rc.d postgresql start $VERSION || exit $?
else
/etc/init.d/postgresql start $VERSION || exit $?
fi
fi
}
=============================================================
Of course the stretch version may be different. Assuming Marco is
even running stretch; he didn't say.
So, to figure out what's breaking, what I would do is put "set -x" at the
start of the configure_version function, and "set +x" at the end of it.
Then try dpkg --configure -a once again. That should give you a shell
trace of the commands being executed in that function, so you can see
which one breaks.
Assuming Marco's versions of these scripts look basically like jessie's.
