Dynamic Software Updating: Linux 4.0 and Beyond

While interesting for a subset of use cases, the reality is that testing software in any new environment must occur before trusting it in production.<p>It would be foolish at this point to trust such upgrades to be &#x27;100% clean slate&#x27; (ie. equivalent to rebooting to the new kernel). Case in point: if boot-time initialization code has changed, eventual reboot may fail.<p>An interesting question may be, then, which operations workflow allows for the proactive testing of all three cases: (1) live upgrade kernel&#x2F;restart services (2) live upgrade&#x2F;reboot&#x2F;restart services (3) traditional upgrade&#x2F;reboot&#x2F;restart services ?<p>For the increase in complexity this creates combined with the sole benefit apparently being nominal speed of upgrade&#x2F;reduced downtime on a per-node basis (in an era where most people running serious services have either outsourced kernel management or are running multi-node HA clustering, anyway), this seems a fairly edge-case feature.

DSU has always been an interesting field to me, and I&#x27;ve wondered why the idea of hotpatching systems while they&#x27;re running has been so relatively underrated.<p>Related is application checkpointing, where you can freeze the state of a process (fds, sockets, pipes, sigmasks, open ttys, etc.) into binary images and overlay them back. Useful for all sorts of nifty cases. See CRIU for a Linux implementation: <a href="http:&#x2F;&#x2F;criu.org&#x2F;Main_Page" rel="nofollow">http:&#x2F;&#x2F;criu.org&#x2F;Main_Page</a>

I wonder if we have a new problem: silently breaking stuff?

I think I would prefer to see the applications be more fault tolerant so that rebooting for a kernel upgrade was no problem as outages are expected. If your software demands 100% kernel uptime then you are just waiting for a failure.

How long before apps run off the trunk itself?