[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package postgresql-9.6 is not configured yet

Tried to solve it by looking at the configuration script but with no success. I gave up and, after securing my database and configuration file, I did an apt-get purge of all postgresql. Then I re-installed it again.

Unfortunately the purge had left the /var/lib/postgres/9.6 and this prevented the correct installation (/etc/postgresql/9.6 was missing). An other purge and rm -rf /var/lib/postgres/9.6. Now the install went correct. After copying back the config files and database files I was back in business.

Problem CLOSED.

Op 27-08-17 om 10:46 schreef Marco DE BOOIJ:
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.

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.maillist@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:
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:


set -e


if [ "$1" = configure ]; then
     . /usr/share/postgresql-common/maintscripts-functions

     configure_version $VERSION "$2"

Following the trail, the configure_version function is defined in
/usr/share/postgresql-common/maintscripts-functions and looks like:

configure_version() {

     # 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
             /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

     _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 $?
                 /etc/init.d/postgresql start $VERSION || exit $?


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.

Reply to: