= Summary =
Upstart is not currently able to retain state across a re-exec. Re-exec is useful in the following scenarios:
(1) The version of Upstart is upgraded.
(2) An Upstart dependency (eglibc, libnih) is upgraded.
(3) Upstart is run from the initramfs.
Without full re-exec support, upgrades are complicated significantly. An example:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/985755
Problem here is that upgrading from lucid to precise causes errors since the version of Upstart running is older than the version of Upstart installed. Full re-exec handling would resolve the problem as that would allow the post-inst script to re-exec upstart such that the running version == the installed version.
= Details =
The problem is no so much the re-exec - that's easy to do, but that on re-exec, the new instance of Upstart needs to retain the state of the old instance (difficult). This state-passing would be critical to having Upstart run in the initramfs for example since without it, the main system instance of Upstart would have no knowledge of existing jobs started by Upstart in the initramfs (for example plymouthd).
= Plan =
- create a pipe.
- fork.
- child creates socket and listens on it.
- child passes details of socket back to parent via pipe
(or could just use well-known location).
- child closes pipe.
- parent re-execs itself (closing pipe), passing a cmdline option to notify
init to read from the socket.
- child sends meta-data on existing jobs through pipe.
- parent parses meta-data and initializes data structures based on this info.
Plan is to use JSON for structured representation of meta-data.
= Perceived issues =
- Cannot restore D-Bus connections. This might not be an issue for the initramfs scenario since there shouldn't be any, but is an issue for Upstart upgrades.
- New version of init being exec'ed must understand all historical JSON syntax quirks if we ever change how we represent objects.
- Child must send its version to the re-exec'ed parent and if that parent detects the child is newer than it, state passing would
be usafe since this scenario is indicative of downgrading the Upstart version. In such instances, the best course of action may be to:
- generate a warning
- log the childs state to a file
- re-exec with no state-passing.
- adding an extra library dependency to /sbin/init is a concern.
- existing JSON libraries may be unsuitable for boot
- would need to select a library with very clean code and
comprehensive tests.
- should we implement a JSON subset parser in NIH for safety?
- time cost (code+tests) may be prohibitive?
= References =
- https://bugs.launchpad.net/upstart/+bug/348455
- https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-event-based-initramfs
- https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html