Pre- and postinstall scripts are needed for the same reasons as they are in normal package management (deb, rpm, ipkg); to migrate settings, change application configuration, overlay some data, start services, etc. In addition, they can be used to update subsystem firmware of embedded device (a "poor man's installer modules").

Today we do check if the client is able to report success and roll back otherwise. This should ensure that no matter what happens you are able to deploy another update (will not lose control). However, custom sanity checkings are needed after preforming the update. This is because custom applications may be required to run successfully before the update is considered successful; e.g. an application that brings up the user interface of the device. A common way to ensure this is to use a Dead Man's Switch - positive acknowledgement - for example the application is expected to put a specific file in place after it successfully starts. If the file is not in place within a timeout (e.g. 1 minute), rollback must be performed. We can implement this using custom sanity checking scripts that are must all return 0 before deployment is considered successful.

See the image below for how these scripts all fit in the picture.

Acceptance criteria

• The user can create directories for 1) preinstall and 2) postinstall and 3) sanity checking executables and point the YP Mender build to it for inclusion when building a mender artifact

• Mender runs preinstall scripts in order according to filename prefix and aborts update if any of them fails (returns nonzero)

• Mender runs postinstall scripts in order according to filename prefix and rolls back update if any of them fails (returns nonzero)

• Mender runs sanity checking scripts in order according to filename prefix after the postinstall scripts and rolls back if any of them fails (returns nonzero)

• If a script hangs, Mender must detect this, kill the script and treat it as a failure. Timeout value must be configurable.

• Deployment log is not sent to server until all of the above scripts have completed (necessary because the log report is the final verification step, and thus all the scripts must have finished by then).

• The output and return code from the scripts (also successful ones) is kept in the mender deployment log and available on the server in case of failure (see , )