| |||||||||||||
Patching runtime kernelPatching runtime kernelPosted Dec 18, 2008 13:20 UTC (Thu) by NAR (subscriber, #1313)Parent article: Followups: performance counters, ksplice, and fsnotify If this is a feature that users really want, they should probably be communicating that fact to their distributors, who can then consider supporting it and working to get it into the mainline. I guess most people who can't afford downtime due to installing a (possibly security) patch already have some kind of HA system where they can already patch the system without downtime...
(Log in to post comments)
Patching runtime kernel Posted Dec 19, 2008 14:48 UTC (Fri) by ballombe (subscriber, #9523) [Link]
Not necessarily... I maintain servers which offer ssh access to researcher to run long running computation. They perform their computation anyway they want (using interactive tools under screen, by running their own code, etc.), and there is no way I can checkpoint their computation, so I cannot reboot the system without killing their computation, which is precisely what I am supposed to prevent. Planned power outage and the like can be handled through suspend-to-disk, but updating the kernel require a reboot.
Since we provide ssh access to a number of users, local privilege escalations are a problem, but I cannot just reboot the system whenever I want.
Of course I would need a high level of trust in ksplice before using it.
Patching runtime kernel Posted Dec 20, 2008 1:35 UTC (Sat) by giraffedata (subscriber, #1954) [Link] What you have isn't actually an aversion to downtime, it's an aversion to reboots. Which another reason to like patching a kernel on the fly.People who are averse to down time (i.e. they can't afford to be offline for three minutes) do usually have some kind of redundant system thing so they can reboot one system, then the other, and thereby install a kernel patch without ever being offline. People who are averse to a reboot (i.e. they don't want to lose the state gathered by the past four days of calculation) might use checkpointing in order to tolerate reboots, but you're at least one example that they don't. Because your users use generic tools, the only way I know that checkpointing could eliminate the pain of reboot is those new virtual machine-based things.
Patching runtime kernel Posted Jun 25, 2009 12:08 UTC (Thu) by epa (subscriber, #39769) [Link]
I think in ten years' time we will look back and see how silly it is to require a reboot every time the kernel is patched. Nowadays it's obvious that waiting for fsck after an unclean shutdown is unacceptable, even though that's the way it was for many years. Anything which can cut the number of reboots is a step forward for desktop usability. We don't want Linux to be that annoying system that wants to restart itself all the time, a title currently held by Windows, but by a thin margin given the frequency of kernel updates by many distros.
So yes, ksplice is wanted; for the remaining 30% of kernel updates that can't be spliced into a running system, working suspend/resume should help to keep downtime to a minimum.
|
|||||||||||||