Call for testing: Upstart 1.4 in Ubuntu

[James Hunt]

On 23/12/11 13:47, Tim Gardner wrote:
> James - The kernel team has plenty of Precise systems that we can 
> update. Given the fundamental nature of Upstart, is there any way to 
> recover short of reinstalling if it completely breaks the boot ? Can we 
> stash the original /sbin/init somewhere and hack the grub command ?
Hi Tim,

Hopefully it won't completely break your system, but if you do experience problems, I'd recommend
rebooting with the '--no-log' option to disable the logging feature. You can't disable the
'setuid'/'setgid' feature currently [1], but you can of course ensure that you've disabled all jobs
that make use of those new stanzas. Generally speaking, we do try to ensure that as features are
added, a corresponding command-line option is added to revert to the previous behaviour thus
disabling the new code path.

On the general topic of recovering a broken system, you *could* stash the previous version of
upstart as /sbin/init.old or similar (you'd need to do the same for /sbin/initctl too of course),
but booting with /sbin/init.old assumes that the new version of init wasn't introduced to cater for
some fundamental interface change in the NIH libraries for example. Note too that any .conf files
referencing initctl would strictly need to be modified to reference /sbin/initctl.old. For Ubuntu,
we could conceivably use the 'alternatives' system to handle this along with static linking to
overcome the NIH issue but that comes with its own issues and would need a lot of extra testing to
ensure all the recovery code paths work as expected.

For testing I do actually maintain a number of inits in /sbin and use a script [2] that boots
setting 'init=/sbin/upstart_menu'. The script presents a menu like the following allowing me to
select which particular version I want to boot with:

  http://people.canonical.com/~jhunt/upstart/utils/upstart_menu.png

The selected init is then exec'd. This works fine for test systems. The 'upstart_menu' could in
principle be hooked into the Ubuntu recovery path, but as stated above, adding this would require a
lot of additional effort to ensure all the recovery paths are failsafe and I wonder if that effort
wouldn't be better directed at just testing the latest init?

Kind regards,

James.
--
James Hunt

[1] - If you think this would be useful please raise a bug.
[2] - http://people.canonical.com/~jhunt/upstart/utils/upstart_menu.sh
____________________________________
http://upstart.ubuntu.com/cookbook
http://upstart.ubuntu.com/cookbook/upstart_cookbook.pdf