apt-get remove maas --purge while maas is running prevents full database purge

Hi Diogo,

The stopping of the daemons is done in the .prerm script. These daemons are being stopped succesfully, but apache2. Which is maybe the reason why the database is not being purged.

If you want to verify this check:

/var/lib/dpkg/info/maas.prerm

Though, this is weird:

dbconfig-common: dumping pgsql database maasdb to /var/tmp/maas.maasdb.2012-09-04-12.29.pgsql.6QEMJ1.
dbconfig-common: dropping pgsql database maasdb.
dropping database maasdb: success.
verifying database maasdb was dropped: success.
dbconfig-common: revoking privileges for user maas on maasdb.
revoking access to database maasdb from maas@localhost: success.
maas-celery stop/waiting
maas-txlongpoll stop/waiting
maas-pserv stop/waiting

This bug was fixed in the package maas - 0.1+bzr971+dfsg-0ubuntu1

---------------
maas (0.1+bzr971+dfsg-0ubuntu1) quantal; urgency=low

  * New upstream release (LP: #1044367)

  [ Julian Edwards ]
  * Fix 02-pserv-config.patch to handle new default tftp directory

  [ Andres Rodriguez ]
  * debian/maas.postinst:
    - include '/MAAS' for DEFAULT_MAAS_URL.(LP: #1033956)
    - Update bzr version to safely upgrade.
  * Add maas-dns package that configures DNS in MAAS (LP: #1030860)
  * Remove cobbler related bits
    - debian/maas.postinst: Drop cobbler configuration
    - debian/maas.install: Drop installation of snippets/preseeds.
    - debian/control:
      + Drop Depends on maas-provision. (LP: #975473)
      + Depends on bind9utils.
      + Depends on python-lockfile (LP: #1037400)
      Add necessary Conflicts/Replaces. Add conflicts to tftpd-hpa and dnsmasq.
      Depends on isc-dhcp-server for maas-dhcp, and syslinux-common.
    - debian/extras/maas-provision: Add missing "$@" (LP: #1040462)
    - debian/patches:
      + 02-pserv-config.patch: Updated. Do not patch cobbler related bits.
        patch tftp config to default.
  * maas-dhcp: Re-add to handle initial configuration of MAAS DHCP server.
  * Allow restart of 'isc-dhcp-server' by adding a sudoers file:
    - debian/extras/99-maas-sudoers: Added.
    - debian/maas.install: Install 99-maas-sudoers
  * Minor improvements on dbconfig-common handling:
    - debian/maas.config: Only call dbc_go when scripts present.
    - debian/maas.postrm: Only call dbc_go when config file exists.
  * debian/maas.maas-celery.upstart: Enable Beat and set scheduler db file.
  * debian/maas-dns.postinst: Set correct permissions. (LP: #1042868)
  * debian/maas-dhcp.config:
    - Ask whether we want to enable DHCP (LP: #1044229)
    - Add debconf question for network interfaces
  * debian/maas.prerm: Stop services before removing database (LP: #1044559)
 -- Andres Rodriguez <email address hidden> Thu, 02 Aug 2012 09:01:43 -0400

I just saw this exact behavior while using a 1.8.0 development package on Trusty. Not sure what the correct process to reopen a bug is, but I think this either wasn't fully fixed, or there has been a regression.

I just saw this one again. I found a relevant discussion here:

https://lists.alioth.debian.org/pipermail/dbconfig-common-devel/2006-September/000627.html

Here's the relevant quote from Sean Finney (the maintainer of dbconfig-common):

"""
i can reproduce your problem... looking in my postgres logs i see:

ERROR: database "zabbix" is being accessed by other users
ERROR: role "zabbix" cannot be dropped because some objects depend on
it

i think this is because the zabbix server has the datbase open while the
removal code is running in the prerm script. if you manually stop the
zabbix server before purging i think you'll see what i'm talking about.

as for how to workaround this... you could manually stop the server
before calling dbc_go when $1 is set to "remove", or you could call the
dbconfig hooks after the #DEBHELPER# macro.

since this could be a general problem with other pgsql+daemon packages,
i'd appreciate suggestions for how to mention this in documentation,
assuming this solves your problem :)
"""

Reply from Michael Ablassmeier:

"""
yes, moving the stanza in prerm above the dbconfig-common call works
nicely and the package successfully purges its database setup. Thanks
for your time! (having a short note somewhere in the Docs might be
helpful since i've discovered the same problem for the mysql part of the
package, even tho mysql doesnt care about it that much)
"""

I attempted to fix this, but haven't gotten anywhere. I am seeing the following errors:

Removing maas-region-controller (1.8.0~beta2+bzr3777-0ubuntu1) ...
 * Stopping web server apache2 *
dbconfig-common: dumping pgsql database maasdb to /var/tmp/maas-region-controller.maasdb.2015-04-06-23.29.pgsql.AhZK0m.
dbconfig-common: dropping pgsql database maasdb.
dropping database maasdb: does not exist.
dbconfig-common: revoking privileges for user maas on maasdb.
revoking access to database maasdb from maas@localhost: failed.

However, I found a workaround:

$ sudo -u postgres dropdb maasdb

You can verify that the maasdb database has been dropped by executing:

$ sudo -u postgres psql

I tried adding "sudo -u postgres dropdb maasdb" to the postrm packaging script for maas-region-controller, but that didn't make a difference.

I think this is a bug with dbconfig-common. It looks like Zbbix is still having this issue:

https://support.zabbix.com/browse/ZBXNEXT-2587