init script status action does not reflect dead postgresql service

Bug #203966 reported by Dustin Kirkland 
10
Affects Status Importance Assigned to Milestone
postgresql-common (Ubuntu)
Fix Released
Undecided
Martin Pitt

Bug Description

Binary package hint: postgresql-common

Hardy, postgresql-common 86

This bug was discovered when encountering Bug #203920, where the postgres database does not start.

That test suggests determining the status of the database by "sudo -u postgres psql -l".

Alternatively, one should also be able to use: "/etc/init.d/postgresql-8.3 status".

However, that action actually lists the postgres clusters and looks for one that is marked "down". In this case, the local daemon is dead and we have no clusters.

The Linux Standard Base specification defines the expected responses and return codes of init script status actions:
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html

According to that document, I think the proper approach would be to exit with "4 program or service status is unknown" if there are no clusters found.

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Debdiff patch attached

Revision history for this message
Dustin Kirkland  (kirkland) wrote :

Assigning to Martin Pitt, per IRC

Changed in postgresql-common:
assignee: nobody → pitti
Martin Pitt (pitti)
Changed in postgresql-common:
status: New → In Progress
Revision history for this message
Martin Pitt (pitti) wrote :

Fixed in trunk.

Changed in postgresql-common:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package postgresql-common - 87

---------------
postgresql-common (87) unstable; urgency=medium

  * Urgency medium since #472930 is an important bug fix.
  * debian/init.d-functions: If there are no clusters, exit with 4 (LSB-code
    for "unknown status") instead of 0 (which means "service is running", but
    it is debatable and confusing whether all clusters are running if there
    are none at all). (LP: #203966)
  * Update Spanish debconf translations, thanks Javier Fernández-Sanguino
    Peña. (Closes: #473405)
  * t/060_obsolete_confparams.t: Run upgrades under
    default_transaction_read_only=on. t/040_upgrade.t still uses the default
    "off", so both cases get tested. This replicates the problem report from
    Karsten Hilbert.
  * pg_upgradecluster: Work with default_transaction_read_only=on.
  * debian/autovacuum.conf, architecture.html: Point out that this file is
    only relevant for PostgreSQL versions earlier than 8.1. Thanks to Ross
    Boylan for pointing this out.
  * Add t/051_inconsistent_encoding_upgrade.t: Check that upgrades from
    pre-8.3 to 8.3 succeed and have correct encodings if the old DB had a
    database whose encoding did not match the server locale. This reproduces
    #472930.
  * pg_upgradecluster: Fix handling of database encodings on upgrade, since
    8.3 now forces DB encodings and server locale to match:
    - With C locale, keep encoding of DBs on upgrade, just as in previous
      versions. (C is compatible with all encodings, and causes lots of string
      functions not to work correctly, but people still use it deliberately.)
    - With other locales, create the target DB manually with a compatible
      encoding, and call pg_restore in a way to not create the target DB and
      automatically convert encoding.
    - Closes: #472930, LP: #207779

 -- Martin Pitt <email address hidden> Mon, 31 Mar 2008 14:15:25 +0100

Changed in postgresql-common:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.