init: transfer state across re-exec

Reported by Scott James Remnant (Canonical) on 2009-03-25
40
This bug affects 8 people
Affects Status Importance Assigned to Milestone
upstart
Medium
James Hunt
0.3
Undecided
Unassigned
PLD Linux
Undecided
Unassigned

Bug Description

Upstart needs to be able to transfer its state across a re-exec. This can then be used for safely restarting (e.g. after a libc or upstart upgrade), and for changing of root device (e.g. initramfs to full system)

This should not use SIGTERM as that doesn't guarantee it's Upstart you're instructing to restart

Changed in upstart:
importance: Undecided → Medium
milestone: none → 0.10
status: New → Triaged
summary: - Transfer state across re-exec
+ init: transfer state across re-exec
Changed in upstart:
milestone: 0.10 → none
Casey Dahlin (cjdahlin) wrote :

Patch to fix this in 0.3.*, newly cleaned up and with test cases.

As discussed on IRC, this patch doesn't transfer nearly enough state to result in a correct re-exec; the event queue and pending D-Bus messages need to be transferred, as does connections to clients, etc.

Marking the 0.3 task as Won't Fix, 0.6 is the current stable release branch

Jacek Konieczny (jajcus-jajcus) wrote :

I think this is a critical feature: working re-exec is a must for proper Upstart upgrades. Currently upgrade from older Upstart versions to 0.6 are fatal to the system: new initctl won't talk to the old and still running Upstart and even a simple reboot may be a problem. When upgrading one 0.6.x Upstart to other 0.6.x only the 'clients' are really upgraded, the old init will be running until the reboot. That is not a big problem for a desktop or embedded systems, but servers should not require reboot after upgrade.

That is why I have started an Upstart branch (lp:~jajcus-jajcus/upstart/state-save) to implement full state saving and re-exec with state transfer. I hope this can help making Upstart a usable (in all cases) replacement for SysVinit.

Jacek Konieczny (jajcus-jajcus) wrote :

@Scott: do the connections to clients and pending D-Bus messages really need transfering? Re-exec would be an exceptional event anyway and the goal is to keep system running with the new init daemon, so upgrade can continue and, maybe, a clean shut-down can be done. Will anything disastrous happen if the pending D-Bus messages are just flushed (errors raised if the requests cannot be handled immediately) and connection are just closed before the re-exec?

On Thu, 2010-05-27 at 13:35 +0000, Jacek Konieczny wrote:

> That is why I have started an Upstart branch (lp:~jajcus-jajcus/upstart
> /state-save) to implement full state saving and re-exec with state
> transfer. I hope this can help making Upstart a usable (in all cases)
> replacement for SysVinit.
>
Awesome!

The biggest mental block I had was getting the state out of libdbus
about the state of connections to Upstart, state of messages, etc.

Restarting Upstart shouldn't drop in-progress commands.

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

description: updated
James Hunt (jamesodhunt) on 2012-08-10
Changed in upstart:
status: Triaged → In Progress
assignee: nobody → James Hunt (jamesodhunt)
James Hunt (jamesodhunt) on 2012-11-22
Changed in upstart:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers