Ksplice provides updates without reboots

Posted Jul 11, 2009 2:05 UTC (Sat) by bbaetz (subscriber, #42501)
Parent article: Ksplice provides updates without reboots

> Companies that have long-running processes, or those who require
> uninterrupted availability, are not particularly fond of this requirement.

Companies who require uninterrupted availability should have more than one machine (and measure SLAs by service, not by individual systems)

Companies that have long-running processes should be able to checkpoint them.

Of course, that's not what happens in the real world, and it would certainly make updates quicker for companies with hundreds of machines to do the updates, but I'd hate to see this being used as a reason to not have proper redundancy...

Ksplice provides updates without reboots

Posted Jul 11, 2009 13:26 UTC (Sat) by gdt (subscriber, #6284) [Link] (4 responses)

Companies who require uninterrupted availability should have more than one machine

That's not likely for some applications. For example, telco customers only want to buy one set top box, not one and a hot spare.

Ksplice provides updates without reboots

Posted Jul 11, 2009 15:35 UTC (Sat) by foom (subscriber, #14868) [Link] (3 responses)

That's not likely for some applications. For example, telco customers only want to buy one set top box, not one and a hot spare.

And telcos don't mind frequently rebooting your set-top-box at 3am. No uninterrupted availability guarantee there... :)

Ksplice provides updates without reboots

Posted Jul 12, 2009 8:50 UTC (Sun) by gdt (subscriber, #6284) [Link] (2 responses)

With respect Foom, some of us are serious about running telephony over fiber to the home. Any scheduled end-to-end outage lasting longer than five minutes is unacceptable due to the obvious safety of life issues. Since we want to field a capable STB, that means we need ways to apply security updates without an initial program load.

We would really like to keep the STB clock rate as low as possible, even if this extends reboot times, in order to get more than four hours full operation and eight hours telephony-only operation from battery. Again, there are obvious SoL reasons for as long a battery run-time as possible.

My concern with ksplice is that it applies only to the kernel. Whereas items like libc are as problematic as the kernel in needing a software restart after updates. A more general approach would be welcome.

Ksplice provides updates without reboots

Posted Jul 12, 2009 9:26 UTC (Sun) by tzafrir (subscriber, #11501) [Link] (1 responses)

With libraries the issue is known and mostly (if not fully) handled already.

Library updates need no such special handling: unless done improperly (by a direct write rather than rename), the old copy would still be present with running processes whereas the on-copy version (and the one used by new processes) will be updates.

This leaves you with long-running processes to restart at your own free time. But that does not require a complete reboot.

Specifically the update procedure of libc on Debian conditionally restarts several daemons, and will always restart the init process. And you can always use "telinit u" to do the latter manually.

Ksplice provides updates without reboots

Posted Jul 13, 2009 9:05 UTC (Mon) by dgm (subscriber, #49227) [Link]

There should be a better way to fix long-running processes than restarting them, more in the line of what Ksplice does. As long as the interface has not changed (function parameters and struct layout if we speak of plain C) it should be doable.