Slashdot Mirror
No More Need To Reboot Fedora w/ Ksplice
An anonymous reader writes "Ksplice, the technology that allows Linux kernel updates without a reboot, is now free for users of the Fedora distribution. Using Ksplice is like 'replacing your car's engine while speeding down the highway,' and it can potentially save your Linux systems from a lot of downtime. Since Fedora users often live on the bleeding edge of Linux development, Ksplice makes it even easier to do so, and without reboots!"
... and it has been free for Ubuntu, as indicated on their web page (http://www.ksplice.com/pricing)
Lisp systems did this 30+ years ago: reload new compiled functions, and keep going. New calls go to the new function, old function becomes garbage when no more threads are executing it.
Great job reading the article... "The service for Fedora and Ubuntu Desktop is free of charge. For other distributions, the subscription fee starts at $3.95 per system a month, after a 30-day free trial."
Here's a cookie... *psst* it's MAGIC
And frankly, I'd still feel a little more comfortable with a reboot, since I'd worry a bit about state consistency of kernel and client processes.
This in theory can be a problem, but each kernel update has to be prepared individually, so someone (once again, this is the theory) has looked at the kernel modifications and made sure it won't cause problems. This isn't an automatic thing that can work with any kernel (don't try to use it to go from a 2.4 kernel to a 2.6 kernel), and if there are major changes, say a new scheduler or something, then someone needs to write code that will move the data from the old scheduler to the new scheduler.
Mainly its used for security updates which are probably a line of code changed, or a function changed, and there is no difficulty with inconsistencies (unless maybe someone is in the middle of trying to exploit the buffer overflow, but they avoid that problem by making sure no threads are in the functions that are being patched). This is my understanding of how it works.
Qxe4
It's voilà. How hard is it to not look like a moron?
Other than just screwing around in your garage it's still $50 a year per server if you actually need.
Processes in the 'D' state cannot be killed, even by root. They're waiting on I/O and nothing short of giving them the I/O they're waiting for or rebooting will kill them.
If your server only takes a few minutes to reboot, then I can see why you wouldn't be so concerned about having to reboot for kernel upgrades. We have Oracle and Sybase database servers that take over 90 minutes to start up all their services (these are 16 and 32 core machines) and not having to reboot them for kernel updates would be a huge win for us.
No, the grandparent means uninterruptible sleep.
Processes sleep in a way that can't be interrupted in some cases. For instance, when writing to a file. The logic of that that if it was possible, the application would have to retry the interrupted call, and since a write is assumed to be uninterruptible nobody tries to check if it was interrupted.
This ocassionally creates problems, like when something in the disk subsystem goes wonky, and a write call never returns, leaving the process sleeping and unkillable forever.
There was a patch to create a killable state, that allows fatal signals to be processed in such cases, since the process would die immediately anyway. I'm not sure how fully is this integrated, but while I remember unkillable processes in the past, I don't think I had any in the last couple of years.