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:Scary analogy

[kumanopuusan]

Given that you mentioned Oracle and 32 core machines, I'm sure you're in a corporate environment that places severe restrictions on your ability to change existing solutions. With that said, your servers are taking more than 90 minutes to boot into a usable state. A huge win for you would be servers that can be rebooted, not servers that never need to be rebooted.

Somehow, I imagined the following conversation.

"Jimmy, are you ok?! There's blood everywhere!"
"OK?! I just had a huge win! I stain-proofed the carpet, so I don't need to worry about the blood anymore."
"Jimmy, are you hurt? Do you need a doctor?"
"What do doctors have to do with cleaning this mess off the carpet?"

(Hopefully my light-hearted tone is apparent. I have nothing but sympathy for fellow cogs still stuck in the machinery of the IT industry. I fell off of my axle and rolled out from under the machine a few years ago. Perhaps it happened because I have (am?) a loose nut. ;-)

Re:Scary analogy

[Jah-Wren Ryel]

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

Scheduled reboots.

Now you are going to say - scheduled reboots is when you do your kernel upgrades.

The problem with that approach is overloading due to bitrot. Kernel ugprades are not the only reason a system will fail to boot. By upgrading and rebooting you are combining the two goals of patching the kernel and verifying that the system is still bootable, which means potentially more effort troubleshooting if something goes wrong. In the past you didn't have the choice to separate out those two tasks. Now you do.

Re:Scary analogy

[MoralHazard]

Get a little imagination, will ya? Here,I'll boil your objection down into two simple premises, for you:

1) In-place kernel upgrades are inherently RISKY to stability, compared with normal reboot upgrades.
2) Reboot upgrades are a LOW COST operation.

You seem to assume that the risk of #1 (upgrade in-place) will always outweigh the cost of #2 (rebooting to upgrade). At the moment, you MAY be correct in that assumption, but we have no basis for any conclusions, yet.

But Ksplice's current business plan is to get ahold of a massive, low-cost testing infrastructure by getting installed by default on as many popular Linux distros (Ubuntu, Fedora, etc.) as possible. Properly executed, a massive testing and development effort should improve KSplice's quality (read: stability) over time.

At some point, if KSplice does it right, in-place kernel upgrades will become stable enough to no longer entail measurably more risk than traditional reboot upgrades. If/When that happens, you'd be a fool to continue reboot upgrading, right? If there's no practical added risk, why should you have to even put up with the inconvenience of a single minute's delay, or the hassle of closing and re-opening all your SSH sessions?

Hell, it's reasonable to imagine that in-place upgrades could even become MORE stable than reboot upgrades (eventually). If that happens, you'd have to be more than a fool to continue rebooting--you'd have to be some kind of technical cargo-cultist, unwilling to offend the Machine Gods by departing from the correct rituals. (There will probably be at least a few of these people--I know some of them, I think.)

For another perspective, consider these:

  - guns vs. bows
  - automobile vs. horse-and-buggy
  - pen/paper vs. typewriter
  - typewriter vs computer
  - multiprocessing vs. single CPU

Reasonable people expect that the earliest incarnation of a new technology will be buggy, unstable, dirty, explosive, unreliable, or otherwise potentially hazardous. But given time to iron out the bugs, there's eventually a tipping point where the original technology no longer fulfills its basic purpose as well as the new-fangled competitor.

Re:Scary analogy

[kabloom]

You always had a choice. You could decide to reboot on a certain schedule and only update the kernel half the time.

Re:how about is linux with memory leaks?

[h4rr4r]

WTF are you talking about? Kill -9 gets rid of apps if you really need too, rebooting is for windows users.

Re:how about is linux with memory leaks?

[Anonymous Coward]

WTF are you talking about? Kill -9 gets rid of apps if you really need too, rebooting is for windows users.

Ideally, kill -9 gets rid of them. Sometimes it won't.

Re:how about is linux with memory leaks?

[maxwell demon]

Unless they are in uninterruptible sleep.

Re:Old hat

[Myopic]

Did you just equate hot-replacing a kernel with adding a function to a runtime environment? Or did I not quite understand? If I understand, then that would be more like, say, upgrading a program without having to reboot, which is unremarkable.

"Next time you open that app, it launches the new version!"

Re:exploitable?

[maxwell demon]

Well, if you manage to get your "updates" accepted by the machine's update process, you pwn the machine after the update anyway, even with conventional rebooting updates.

Re:Old hat

[imbaczek]

back then, the runtime environment on a lisp machine was pretty much the kernel.

Old hat

[Anonymous Coward]

So, Linux has finally caught up to Smalltalk-80, maybe.

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:Old hat

[Kaz Kylheku]

No, I equated hot-replacing sets of functions in a run-time to hot-replacing a kernel (which is a set of functions).

"Next time you open that app" isn't hot-replacement if you are first required to exit the current instance, such that a new process is started.

Re:Old hat

[TheRaven64]

Actually, the Lisp version was more impressive. The entire OS on the Lisp machines was written in Lisp and was introspectable. You could, at run time, inspect the code for the running system, modify it, and have the code compiled and the new version replace the old one without any downtime. Ksplice, in contrast, requires a separate program to do the compilation and requires a user to manually do some merging of nontrivial changes.

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.