Forgot your password?
typodupeerror
Red Hat Software Upgrades Linux

No More Need To Reboot Fedora w/ Ksplice 262

Posted by CmdrTaco
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!"
This discussion has been archived. No new comments can be posted.

No More Need To Reboot Fedora w/ Ksplice

Comments Filter:
  • by odies (1869886) * on Tuesday August 31, 2010 @03:20PM (#33429410)

    Well it's an old technique actually. kexec have been there for ages.

  • by JustAnObserver (1194117) on Tuesday August 31, 2010 @03:28PM (#33429530)
    ... and it has been free for Ubuntu, as indicated on their web page (http://www.ksplice.com/pricing)
  • Old hat (Score:5, Informative)

    by Kaz Kylheku (1484) on Tuesday August 31, 2010 @03:29PM (#33429548) Homepage

    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.

  • Re:It's free? (Score:3, Informative)

    by cwrinn (1282510) on Tuesday August 31, 2010 @03:34PM (#33429598)
    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."
  • Re:interesting (Score:5, Informative)

    by phantomfive (622387) on Tuesday August 31, 2010 @03:46PM (#33429732) Journal

    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.

  • Re:Hmm... (Score:3, Informative)

    by Anonymous Coward on Tuesday August 31, 2010 @03:49PM (#33429758)

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

  • Servers (Score:4, Informative)

    by DreamArcher (1690064) on Tuesday August 31, 2010 @03:50PM (#33429772)
    Other than just screwing around in your garage it's still $50 a year per server if you actually need.
  • by quercus.aeternam (1174283) on Tuesday August 31, 2010 @04:17PM (#33430076) Homepage

    kexec restarts the entire software stack while leaving hardware running.

    From what I can tell, ksplice does not require a software restart or hardware restart. This isn't explicitly stated, but it is implied by the usage instructions: http://www.ksplice.com/uptrack/using [ksplice.com]

  • by Anonymous Coward on Tuesday August 31, 2010 @04:22PM (#33430122)
    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.
  • Re:Scary analogy (Score:5, Informative)

    by jimmyharris (605111) on Tuesday August 31, 2010 @04:25PM (#33430162) Homepage
    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.
  • by vadim_t (324782) on Tuesday August 31, 2010 @04:39PM (#33430294) Homepage

    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 [lwn.net] 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.

  • Re:interesting (Score:3, Informative)

    by Simetrical (1047518) <Simetrical+sd@gmail.com> on Tuesday August 31, 2010 @05:21PM (#33430690) Homepage

    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.

    I like your Latin-based distinction of "free" better than the free-as-in-beer v.s. free-as-in-speech method. I'll have to remember it for the next time I give a speech on OSS at the Roman senate.

    Libre is French. The Latin equivalent is liber.

  • Re:interesting (Score:2, Informative)

    by Anonymous Coward on Tuesday August 31, 2010 @07:19PM (#33431488)

    Lorem ipsum dolor sit amet

  • by haruchai (17472) on Tuesday August 31, 2010 @07:56PM (#33431658)

    I recall seeing this problem with NFS some years back - don't know if it's still the case. The clients with open connections would freeze solid if the server abruptly dropped the connection, for whatever reason, and would stay
    that way until either forcibly rebooted or until the server reconnected.
    I think that the server could be mounted in a "soft" state to prevent that but was told there was too much of a performance penalty.

  • Re:Old hat (Score:3, Informative)

    by Abcd1234 (188840) on Tuesday August 31, 2010 @09:38PM (#33432136) Homepage

    Incidentally, Smalltalk images work similar. For a fun time, open up a Squeak image and start digging around. Now *that* is open source software.

  • Re:Scary analogy (Score:2, Informative)

    by natehoy (1608657) on Tuesday August 31, 2010 @09:59PM (#33432218) Journal

    I know Windows 7 has improved startup times dramatically over XP, and that's great. My father has a Windows 7 machine, my mother does, several friends do, and I like it. It does start fast.

    But, no, to answer your question, startup takes nowhere near a minute in Mint. Probably closer to the 15 seconds you report from Windows 7, though I'll admit I haven't timed it with a stopwatch so I can't give you an exact time.

    "Boot" and "reboot" are different terms, though.

    So, to be clear: My "under a minute" was from the moment I told Mint to reboot to the moment I'm back in a fully operational desktop again with my basic programs running (Firefox and Thunderbird). So that figure includes powerdown, POST, OS startup, login to my primary account, launching my programs, and being back where I started when I started telling it to shut down.

    And it's probably closer to 40 seconds, if I had to guess at a more precise time. But that's a guess. And Windows Seven might still beat the pants off it, and if it does I'm happy for you if that sort of metric is important to you. Personally, I'm happy with anything pretty much under a minute or so.

    The reboot-to-patch-everything treadmill really sucks, and I'm glad it's largely behind us as a computing community across most personal computing platforms.

    It's also great that everyone (on all platforms) has put so much work into reducing boot times for those times when it is necessary (or safer) to just reboot rather than trying to patch-in-flight.

  • Re:Hmm... (Score:3, Informative)

    by deek (22697) on Wednesday September 01, 2010 @03:03AM (#33433164) Homepage Journal

    As much as I hate to weigh in on a grammar nazi thread, using a split infinitive is not necessarily incorrect.

    http://en.wikipedia.org/wiki/Split_infinitive#Current_views [wikipedia.org]

    If the meaning is obvious and unambiguous, let it be, I say.

  • Re:Old hat (Score:3, Informative)

    by TheRaven64 (641858) on Wednesday September 01, 2010 @10:30AM (#33436308) Journal

    Did the Lisp machine let you change the hardware running those lisp expressions? No?

    Not exactly, but with a Lisp Machine everything other than the hardware was modifiable. The entire run-time environment was written in Lisp. The Squeak VM includes things like the frame buffer, for example, which are statically compiled.

    SqueakNOS is more impressive than Squeak, because everything from the interrupt handler layer and up is written in Smalltalk and can be modified. This is pretty close to being equivalent to a Lisp Machine. The only bits you can't modify at run time are the bits that are written in assembly and set up the interrupt vectors, and a few bits of the VM that are statically compiled.

    For a modern production system that does this incredibly well, take a look at the OpenFirmware implementation used in the OLPC machines. They boot to an interactive FORTH environment that lets you modify everything in the boot firmware.

    The thing that makes ksplice interesting is that it does it in C. As I said in the post that was marked flamebait, this is a pretty trivial problem in late-bound languages, but a general solution in C is impossible. A specific, good-enough, solution is therefore interesting.

If God had a beard, he'd be a UNIX programmer.

Working...