package acpid 1.0.6-9ubuntu6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

Thanks for your bug report. I can confirm that this happens when upgrading from a pre-upstart version.

 Setting up acpid (1.0.6-9ubuntu6) ...
 * Stopping Hardware abstraction layer hald
   ...done.
acpid start/running, process 21054
 * Starting Hardware abstraction layer hald
invoke-rc.d: initscript hal, action "start" failed.
dpkg: error processing acpid (--configure):
 subprocess installed post-installation script returned error exit status 1

The reason is that hal has already been restarted (by upstart?) when the acpi.postinst tries to restart it.

invoke-rc.d is not supposed to be failing in these circumstances - policy documents that the 'start' option to an init script is supposed to return success when the job is already started. And since this bug was first filed, upstart-job has been fixed (in upstart 0.6.3-4) to implement this behavior.

So I think this bug is already fixed elsewhere, and in any case ignoring errors from invoke-rc.d would be the wrong thing to do here - anything causing invoke-rc.d to fail is a bug somewhere else that needs to be located and fixed.

Tormod's log confirms that the upgrade failure happened with the old upstart, so I'm marking this as fixed in upstart. Changelog for the fixing version of the package:

upstart (0.6.3-4) karmic; urgency=low

  [ Scott James Remnant ]
  * Reduce the priority of the stopped by/continued by messages so that
    they are only shown when --verbose on the kernel command-line.
    LP: #401333.
  * Add a hack to look for /dev/.initramfs/*.pid files on startup and
    "fake" start jobs of those names. Basically this means that "status"
    and "stop" work for things like bootchart and usplash.
  * Implement a "reload" command in initctl that retrieves the current pid
    of the job and sends it the HUP signal. LP: #433544.

  [ Steve Langasek ]
  * debian/upstart-job:
    - give proper policy-compliant behavior of the start command: detect if
      the job is already running using upstart status, and if so return success.
    - same for the stop command: return success if the job is already stopped.
    - when $DPKG_MAINTSCRIPT_PACKAGE is set, don't spit warnings out because
      it's not the user's fault - we're being invoked by a maintainer script.

Is that the same for "start"? Is start xx || : also undesirable?

So what Do I do? Ignore it? Or do something else?

shalom, it should not be a problem now that a newer package will be candidate for installation.