The other day, we discovered that an important package on one of our Ubuntu servers had wound up in what the package system considered an odd state. The only relatively obvious sign of this was that 'apt-get -u upgrade' reported that there was work to do despite not having any packages to install or upgrade (unfortunately I didn't save the specific output). This state was sticky because for reasons beyond the scope of this entry, the package's postinstall script was reporting an error.

Since we hadn't really noticed this package being in this state, one of the questions I had in the aftermath was if we had any other packages on any other machines in a similar state, or more generally in any unexpected states. While there are a number of ways you can dig out this information, the tool you really want to use is dpkg-query. Specifically, to dump out package states and the package names:

dpkg-query -W -f '${db:Status-Status} ${binary:Package}\n'

The various package states are documented in the dpkg manual page. The two package states you will typically see are "installed", for packages that are properly installed, and "config-files", for packages that have been removed but not purged (in the Debian package system, this leaves their configuration files behind). I believe that our package had the "half-installed" state, but it might have been "half-configured".

(The package had been initially installed without problems, then a subsequent upgrade hit the postinstall script problem because of an unrelated system change, out but we (I) didn't notice at the time in all of the 'apt-get' output. As far as the package state goes, I thought I took good notes while I was looking into the issue, but evidently not.)

If you're cautious, you may also report what dpkg-query calls the "status eflag" (and dpkg calls the package flags):

dpkg-query -W -f '${db:Status-Eflag} ${db:Status-Status} ${binary:Package}\n'

This is almost always going to be "ok", but if it's every something else, you have a problem. The only other currently documented value is "reinstreq"; I don't know if a package can wind up with that flag but still report as "installed" (or "config-files") instead of some other state that stands out.

Fortunately we had no other packages in any unexpected states. While I could create some sort of automated monitoring and alerting for it in our metrics system, it's sufficiently uncommon that that's probably not worth it.

(Especially since monitoring would require another little script that we'd have to remember, maintain, and so on. Code is an overhead, and this includes little sysadmin scripts.)