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!"

Comments

Scary analogy

[Xest]

"Using Ksplice is like 'replacing your car's engine while speeding down the highway,'"

So in other words it's something you'd never want to risk doing because it'd almost certainly cause a crash?

I think they should've thought about a different analogy for this one...

Re:Scary analogy

[natehoy]

True. The in-place kernel upgrade is somewhat safer than their analogy might imply, but it does lead to an interesting point. Why would you want to do this?

Personally, I'm OK with having to reboot my Linux machine when I change kernels, mostly because it's the only time Linux DOES ask me to reboot. To be fair, Microsoft and especially third party Windows software vendors have gotten a lot better about this in the last few years, so infrequent need to reboot is now a pretty solid feature on both Windows and Linux.

In any case, when I get a new kernel, I can install the new kernel and continue running along on the old one as long as I wish to, then reboot to apply the new kernel at a convenient time. Rebooting Linux Mint takes less than a minute from powerdown to login, and I know I haven't run into any risky process locks or anything during the upgrade process. Plus, I like the fact that the "older" kernel is always available to me on the boot menu in case something goes horribly wrong with the new one.

But I'm not all that uptight about "uptime". It's a home computer. If I have to reboot it once a month or so to apply the latest kernel, I'll reboot it. For my purposes, I don't see any added value for the extra risk (however slight) an "in-place upgrade" would introduce.

If I were running a "must be up 24/7" machine, I could see this as a benefit, but chances are at that point I've load-balanced a couple of machines and the cluster can stand a "rolling reboot" of the machines far better than it could stand a botched upgrade.

I still love the idea, and applaud the folks who managed it, but I don't think I see a real reason for it other than "wow, that's pretty nifty". It doesn't seem possible without introducing at least a little bit of risk, and it doesn't seem that the people who would really need it would be all that tolerant of the risk.

Re:Scary analogy

[Leebert]

And how would you know for sure that it would actually boot correctly the next time you actually *need* to?

There is nothing worse than having an actual unexpected reboot (UPS hiccup, whatever), and finding that the system that has been up for 3 years isn't booting, and not having ANY idea which patch put in place in the intervening time actually broke it.

Not that, ahem, I speak from experience, or anything...

Occasional rebooting is good, if for no other reason than making it happen in a controlled situation so you aren't surprised in an uncontrolled situation. If you really need the 100% uptime, then by all means, design a proper high availability system.

Re:interesting

[scheme]

Seriously? I patched 5500 linux servers in 24 hours *by myself*, all the while they were churning through collider data from the LHC. This would be, in my opinion, what I would call a production environment. Shortcuts are nice, but sometimes you don't need them if your environment is engineered properly.

That's slightly different. I assume you're at a CMS or ATLAS T2 center and frankly most of those systems were worker nodes that could be taken down for a minute or too for a reboot as jobs were drained off of them and they went idle. A quick reboot and they'll show up in condor or pbs a minute or two later and start processing jobs. The gatekeepers and gateways for the SE would be more complicated but if you got them up within a minute or two, most if not all of the running jobs wouldn't notice.

Re:Now this is even more applicable

[Anonymous Coward]

The uptime obsession is crazy. Rebooting once in a while is useful, if only to see that you can still get everything running again from a complete stop. Kernel updates in particular can cause all kinds of problems at boot time. If you don't check the boot sequence, you'll almost certainly have forgotten what you changed that killed your cold boot ability when you need it for some other reason (moving servers, power failure, hardware upgrade, ...).

Re:LOL Linux users

[mabhatter654]

well for starters, Apple doesn't officially support using Blades or Virtual Machines (they did "allow" VMWare to do it", but only on Mac Hardware) which are where many enterprise Linux installs are living nowdays on IBM, Dell, or HP farms. Apple hardware doesn't really have an enterprise presence or connections to the type of SAN hardware running in many places. You have to ASK to buy a Mac and not many IT departments would allow that. You don't have to ASK to try out a Linux install, you can beg "forgiveness" later on because generally you won't cost the company monie$$, or at least risks they wouldn't have spent money on in the first place. While Macs are cool, as far as enterprise uses, it is still pretty limited. I have several macs (so I'm not a hater) but I could never get my IT manager to take them seriously.