Package postinst always fail on first install when using systemd

Thank you for taking the time to report this bug and helping to make Ubuntu better.

It looks like openhpid is not expected to work until it is configured. The package ships OPENHPI_UNCONFIGURED = "YES" in /etc/openhpi/openhpi.conf. This causes a maintainer script failure on first install of the package. I think this has probably happened since the systemd switch and that the previous Sys V init script was probably just a noop.

To fix this problem, you should adjust /etc/openhpi/openhpi.conf to your needs and then run "sudo dpkg --configure -a" to restart the daemon and fix the package installation.

So this bug is part user error since /etc/openhpi/openhpi.conf needs configuring manually, but also part packaging bug because the package will never install successfully the first time.

Status changed to 'Confirmed' because the bug affects multiple users.

Bug 1479661 may be a duplicate of this.

Fedora added a very basic systemd job at:
  http://pkgs.fedoraproject.org/cgit/openhpi.git/tree/openhpi-3.4.0-systemd.patch

Thats not much help, as that just moves the failure to a native systemd job.

openhpid exits 8 (SA_ERR_HPI_ERROR) when 'OPENHPI_UNCONFIGURED = "YES"'.
That might seem helpful, but it can also exit that on other conditions such as 'err("Could not create first domain!")'.

it seems like we either need to:
 a.) not try to start and disable the service based on some reading of the conf file (if it has 'OPENHPI_UNCONFIGURED = "YES") . it seems like possibly execstartPre might be useful or ExecStartPost
 b.) patch source to exit some specific value on "unconfigured" and do not consider that fail

Anyone have any suggestions?

This might be a case of dh_installinit --no-start, to avoid trying to start the service on installation? Alternatively, if the daemon exits with a special code when it is unconfigured, the unit could grow a SuccessExitStatus=8. But semantically that's slightly confusing as you don't really want to claim that the unit started successfully when in reality it's not running.

Note that there are also a bunch of Condition*= which you could add to a unit (man systemd.unit), but it seems the config file is already there, so you can't do something like ConditionPathExists=/etc/openhpi/openhpi.conf

Third option: Use dh_installinit --error-handler=true (or a locally defined function which does something more elaborate)

summary: by adding a systemd openhpid.service file we have parity with previous upstart behavior

== details ==
I've found that installing a systemd service file fixes the problem, and have uploaded the fix to wily.
The designed behavior of openhpi is to exit 8 unless the user edits /etc/openhpi/openhpi.conf to remove:
  OPENHPI_UNCONFIGURED = "YES"

(sudo sed -i 's,^OPENHPI_UNCONFIGURED,#OPENHPI_UNCONFIGURED,' etc/openhpi/openhpi.conf).

The '/etc/init.d/openhpid start' would exit 0 in this case. Upstart would happily go on, and not cause package installation failure.

When init changed to systemd, systemd-sysv-generator started handling the start of the service during installation. That would correctly identify that the forked service started via '/etc/init.d/openhpid start' exited non-zero and pass the failure up to the install script. The install script would then exit non-zero, causing the bug.

So, we ended up with a possibly more correct behavior that caused installation failure.

The interesting thing is that adding the openhpid.service file actually changes the behavior so that the install now succeeds although the service exits non-zero.

The result is that we now act as we did before:
  * fresh installation of openhpid succeeds
  * 'service openhpid status' immediately after clean install will show the service failed to start.

This bug was fixed in the package openhpi - 2.14.1-1.4ubuntu1

---------------
openhpi (2.14.1-1.4ubuntu1) wily; urgency=medium

  * sync with debian.
  * remaining changes:
    - debian/openhpid.service: add systemd service file (LP: #1488453)

 -- Scott Moser <email address hidden> Tue, 29 Sep 2015 14:55:06 +0000

Hello Anders, or anyone else affected,

Accepted openhpi into vivid-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openhpi/2.14.1-1.3ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Checked again with 2.14.1-1.3ubuntu2.1 from vivid-proposed. While I've not done any functional testing against openhpid itself, apt and dpkg now exit cleanly, whereas they did not @ ubuntu2.

ubuntu@juju-beis1-machine-3:/etc/apt/preferences.d$ apt-cache policy openhpid
openhpid:
  Installed: (none)
  Candidate: 2.14.1-1.3ubuntu2
  Version table:
     2.14.1-1.3ubuntu2.1 0
        400 http://archive.ubuntu.com/ubuntu/ vivid-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     2.14.1-1.3ubuntu2 0
        500 http://nova.clouds.archive.ubuntu.com/ubuntu/ vivid/main amd64 Packages

ubuntu@juju-beis1-machine-3:/etc/apt/preferences.d$ sudo apt-get install openhpid/vivid-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '2.14.1-1.3ubuntu2.1' (Ubuntu:15.04/vivid-proposed [amd64]) for 'openhpid'
The following NEW packages will be installed:
  openhpid
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/103 kB of archives.
After this operation, 457 kB of additional disk space will be used.
Selecting previously unselected package openhpid.
(Reading database ... 68000 files and directories currently installed.)
Preparing to unpack .../openhpid_2.14.1-1.3ubuntu2.1_amd64.deb ...
Unpacking openhpid (2.14.1-1.3ubuntu2.1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for systemd (219-7ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
Setting up openhpid (2.14.1-1.3ubuntu2.1) ...
ubuntu@juju-beis1-machine-3:/etc/apt/preferences.d$ echo $?
0

This bug was fixed in the package openhpi - 2.14.1-1.3ubuntu2.1

---------------
openhpi (2.14.1-1.3ubuntu2.1) vivid-proposed; urgency=medium

  * debian/openhpid.service: add systemd service file (LP: #1488453)

 -- Scott Moser <email address hidden> Thu, 01 Oct 2015 13:52:13 -0400

The verification of the Stable Release Update for openhpi has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.