Slashdot Mirror

← Back to Stories (view on slashdot.org)

No More Need To Reboot Fedora w/ Ksplice

Posted by CmdrTaco on from the stacking-your-nines dept.

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

32 of 262 comments (clear)

  1. Awesome! by mark72005 · · Score: 5, Funny

    But do the windows "snap" to one side of the screen? See? Simple! ($100 please)

    1. Re:Awesome! by AhabTheArab · · Score: 4, Funny

      That was MY idea. I thought of it on my own and e-mailed Microsoft to tell them to make my PC simpler - and you know what? They did!

    2. Re:Awesome! by numbski · · Score: 3, Funny

      Ah, so Windows 6.1^H^H^H7 is all *your* fault!

      --

      Karma: Chameleon (mostly due to the fact that you come and go).

  2. Now this is even more applicable by MrEricSir · · Score: 5, Funny

    http://www.imagepoop.com/image/660/I-Reboot-As-Much-As-I-Get-Laid.html

    --
    There's no -1 for "I don't get it."
    1. Re:Now this is even more applicable by Anonymous Coward · · Score: 4, Insightful

      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, ...).

  3. Scary analogy by Xest · · Score: 5, Insightful

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

    1. Re:Scary analogy by EkriirkE · · Score: 4, Funny

      It makes a bloody mess? I don't know about that...

      --
      from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
      to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
    2. Re:Scary analogy by natehoy · · Score: 4, Insightful

      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.

      --
      "This post contains words, known to the State of California to cause thought. Wash brain thoroughly after reading."
    3. Re:Scary analogy by Spad · · Score: 4, Funny

      They should have stuck with their original slogan: "Using Ksplice is like updating your kernel without rebooting"

    4. Re:Scary analogy by jimmyharris · · Score: 5, Informative

      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.

    5. Re:Scary analogy by Leebert · · Score: 5, Insightful

      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.

    6. Re:Scary analogy by MoralHazard · · Score: 3, Insightful

      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.

    7. Re:Scary analogy by kabloom · · Score: 3, Insightful

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

  4. interesting by idontgno · · Score: 3, Interesting

    this may be based on Free software (residing in the machine needing its kernel patched), but it appears that patch preparation is based on a subscription service provided by the Ksplice Uptrack people. That's the part which is (selectively) free-as-in-beer. This isn't organic to the kernel or the normal methods of kernel updating.

    That means there's libre-free software and a service provided by a non-distro company which is, for selected distros, gratis-free. For now.

    The technical description sounds like the ancient OS patching techniques the old mainframes I used to work on used.

    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. But, I guess smarter people than me says it OK, so what do I know?

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
    1. Re:interesting by bsDaemon · · Score: 4, Interesting

      When you have around 1500 production servers to patch, such as with the memmap 0 bug last year, doing them one-by-one, or even in small batches, remotely over IP KVM takes a long-ass time. This is nice for those types of situations.

    2. Re:interesting by phantomfive · · Score: 4, Informative

      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
    3. Re:interesting by TooMuchToDo · · Score: 4, Interesting

      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.

    4. Re:interesting by scheme · · Score: 5, Insightful

      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.

      --
      "When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
    5. Re:interesting by TooMuchToDo · · Score: 5, Funny

      Your post is accurate =) *shakes fist*

  5. Ubuntu has it already by JustAnObserver · · Score: 3, Informative

    ... and it has been free for Ubuntu, as indicated on their web page (http://www.ksplice.com/pricing)

  6. Old hat by Kaz+Kylheku · · Score: 4, Informative

    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.

    1. Re:Old hat by Shikaku · · Score: 4, Funny

      diff mainline patch
      )

  7. Re:It's free? by cwrinn · · Score: 3, Informative

    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
  8. Re:how about is linux with memory leaks? by maxwell+demon · · Score: 3, Insightful

    Unless they are in uninterruptible sleep.

    --
    The Tao of math: The numbers you can count are not the real numbers.
  9. Re:So... by Ironhandx · · Score: 5, Funny

    Windows user is middle of the road. He has brains and money but not enough of either.

  10. Re:Hmm... by Anonymous Coward · · Score: 3, Informative

    It's voilà. How hard is it to not look like a moron?

  11. Servers by DreamArcher · · Score: 4, Informative

    Other than just screwing around in your garage it's still $50 a year per server if you actually need.

  12. Debugging in space: a case for dynamic systems. by drainbramage · · Score: 3, Interesting

    Looks like you might be referring to this http://developers.slashdot.org/comments.pl?sid=130313&cid=10876098

    --
    No brain, no pain.
  13. Re:how about is linux with memory leaks? by Anonymous Coward · · Score: 4, Informative

    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.

  14. Re:how about is linux with memory leaks? by vadim_t · · Score: 4, Informative

    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.

  15. Re:LOL Linux users by mabhatter654 · · Score: 4, Insightful

    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.

  16. Re:Hmm... by Sulphur · · Score: 3, Funny

    My tires always rotate while driving down the road. If you had an axle up your ____, you would rotate too.