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!"
But do the windows "snap" to one side of the screen? See? Simple! ($100 please)
Changing your car's oil while driving down the highway could be tricky, too.
Remember to maintain your supply of
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."
Isn't everything in linux?
"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...
how about is linux with memory leaks? is the base os good? what about X? most of the apps? what about apps get stuck in background that need a reboot to unload?
Because most people here have more brains than money.
If it is REAL WORK then you're doing it wrong. :p
Remember to maintain your supply of
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.
Price?
WTF are you talking about? Kill -9 gets rid of apps if you really need too, rebooting is for windows users.
... 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.
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.
If not... you need a kernel update!
Unless they are in uninterruptible sleep.
The Tao of math: The numbers you can count are not the real numbers.
How long before it is used to exploit machines, what could possibly go wrong.
Got Code?
Linux user = more brains than money ...?
Mac user = more money than brains
Windows user =
I've been waiting for years!
watch uname -r
(from the man page)
I should put something clever here. Maybe someday.
Not only applications can possibly leak memory, but the kernel itself, too.
In which case, use kill from root.
Too early. The next story on whiskey made from urine was brewed specifically for you, though.
Other than just screwing around in your garage it's still $50 a year per server if you actually need.
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.
WTF? Can anyone explain why they would do it this way?
Using Ksplice is like changing your tampon while speeding down the highway
As in it's something that's unnecessary (if not nonsensical) for the majority of drivers/users anyway?
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
How much is your time worth? Would you rather spend it recompiling your kernel or getting actual work done?
TFA says that they are making the code available to be directly included in the Fedora distribution. Fedora is pretty strict about what they include in their distribution so if it's included it will have to be Free Software.
Accordingly, what's to prevent anyone from taking the Fedora version and porting it to the other Linux distributions that this outfit is currently charging a user fee for?
Other comments above state that the use of this thing requires a specially crafted patch instead of the regular "here's a new kernel package" that you get from the distribution's repositories. If so, then wouldn't it be worthwhile to use the technology that is revealed in the Free Software Fedora version to make a patch-creating kernel update reader program (KURP - Kernel Update Reader Patch) that would scan a standard kernel update and create the required patch?
Then this technology could become available as a stock feature in all Linux distributions, without charge.
Of course, if the technology isn't Free Software then this whole scheme goes off the rails, but if it's not Free Software it won't be included in Fedora anyway.
If you're a zombie and you know it, bite your friend!
Since that bug with the exec-shield patch that occasionally killed a perfectly innocent process. It will probably just add more bugs which no-one will notice or care about,
Wasn't Fedora always intended to be a test-bed for Red hat Linux anyway?
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
So, Linux has finally caught up to Smalltalk-80, maybe.
Looks like you might be referring to this http://developers.slashdot.org/comments.pl?sid=130313&cid=10876098
No brain, no pain.
Wow, how cool! It's almost like before this happened, I couldn't even USE ksplice!
Oh wait, it's been running on my Debian box for months...
nevermind. *crickets chirping*
If you have an application where the operating system can never restart, you are doing it wrong. Even fault tolerant systems go down sometimes.
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.
I've always been told by the Linux fan-bois that they haven't rebooted their computers since 1847. I thought Linux never needed a reboot already. Who do these Ksplice people think they are fooling?
SIGKILL dude, `kill -9 pid` will take care of it...
unless you are referring to zombie processes, in which case: who cares? They don't consume shit for resources, and they almost never happen unless you go out of your way to make it happen.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
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.
WTF are you talking about? Kill -9 gets rid of apps if you really need too, rebooting is for windows users.
Unless it's gone down a a rat hole in the I/O sub-system and the process won't get the signal to die until the syscall returns (which it never does in the case of hardware problems, or network issues in the case of NFS).
I've come across quite a few unkillable processes on various Unix flavours.
I don't recompile kernels, the bloody computer does.
I've seen this happen to processes fairly recently. (A couple months ago.) It wouldn't have bothered me, but it meant I couldn't replace the files they were writing to. My workflow at the time was sufficiently inflexible that this basically required me to reboot to continue working when it happened. I stopped using the program that caused the problem, and improved my workflow to be more flexible. I'd hate to run into the problem again though. I'd love to see a patch like the one you pointed to become an integral part of disk I/O in the future.
Insert self-referential sig here.
...but does it have support for smooth full-screen Flash video yet?
(It's http://xkcd.com/619/ for those of you who still have question marks over your heads)
Tired of FB/Google censorship? Visit UNCENSORED!
Okay, so even suppose this is perfectly reliable. Let's say I'm running a high-availability server and can't stand any downtime. Now when my kernel needs an update, I don't have to reboot, great!
So what about when, say, libc needs an update? As long as programs are still using it, they'll be using the outdated version. Am I supposed to restart all programs using libc? That will cause downtime just like a reboot (although maybe a bit less).
Or what about when I need a hardware upgrade? Or there's a hardware failure? Or what happens when that critical application requiring 100% uptime needs a security fix? What am I supposed to do then?
There's no way to avoid outages completely for any given machine. PC OSes aren't meant for that. Any high-availability service needs to be able to tolerate the failure of any one machine. So why not just reboot it when you get a critical update to the kernel or major system library? That way you know that the machine reboots properly, too.
My suspicion is that this is mainly meant to lure in Linux users who want the "please reboot your computer" messages to go away. But those messages are misleading. If you Ksplice and never reboot, your libraries will remain outdated indefinitely – it's not secure. Distros would do better to ask for reboots only on security updates, and to do so for libraries and running applications (if they can't be easily restarted) as well as kernel updates.
MediaWiki developer, Total War Center sysadmin
And you can easily put in an icon that forces a process that owns a Window to quit (it looks like a broken window on Ubuntu/GNOME). The only times I have to reboot is when X.org takes out the desktop *and* the keyboard, or when ACPI fails. Those things things still happens too often.
It shouldn't be a program's fault.
I'd check for things like filesystem corruption, disk problems and other hardware issues or network problems if over the network. Try "dmesg" and see if there's anything unusual in the log when the problem happens. If it's none of that, it may be that the program is indeed running into a kernel bug somewhere. Trying a newer/older kernel to see if it makes any difference could clarify something in such a case. And if it looks like a kernel issue, report it to the kernel developers.
When your kernel needs an update, you use ksplice. If libc needs an update, you hot-patch libc in the same way. "But there's no way to do that!", you say? Actually, there is--it's just proprietary. The place I work at has implemented userspace hotpatching on linux for several architectures.
Interestingly, Solaris had (past tense, as it's dead) a command to remove zombie processes.
preap
I never had the chance to use it, but I thought it had a cool name.
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.
Pain is merely failure leaving the body
Major Linux distributions ask their users to install a kernel update roughly once each month. Before Uptrack, each such update required a reboot. Until a system can be updated, it remains vulnerable to security flaws. By allowing users to install kernel updates without downtime, Uptrack slashes the cost of system administration [...]
Slashes the cost how? So... your sysadmins are all working on putting out fires caused by attacks on vulnerabilities, since they didn't get the patches in right away? Or they're just sitting around idle, waiting for the exact, once-a-month moment to reboot the computer.
You'll still need the sysadmin to apply these updates anyway, Ksplice or not. It's not like Ksplice will come to your machine room and install the updates themselves. And it's not like applying the updates the moment they are released will guard you against all exploits either.
You need sysadmins to fix things when attackers break it. You need sysadmins to fix things when users break it. You need sysadmins to fix things when it breaks itself. Preventative maintenance, housekeeping, and not to mention updates to every other piece of software on a server other than the kernel. Seriously, rebooting a machine takes up the least amount of my time. I type `sudo reboot`, enter my password, and the machine does the rest. If I've done my job correctly I don't have to sit there and hand-hold the machine while it boots itself.
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.
Welcome to 2003, kids. Microsoft has been doing this for a long time.
See: http://technet.microsoft.com/en-us/library/cc781109(WS.10).aspx
Or go look up "Windows Hotpatching".
There's more requirement for a windows version!
Linux reboots are hardly ever required - Windows on the other hand - Mmm
WTF are you talking about? Kill -9 gets rid of apps if you really need too, rebooting is for windows users.
If you've never had a process that kill -9 couldn't kill, you can't have been using Linux (or any other UNIX-like system) for very long.
Rest assured it's quite possible to get a system into a situation where a reboot is _required_.
if you cared to look at your own link, you'd see that it is about patching files without the need to reboot. On a running system the kernel is entirely in the memory.
Also the statistics Microsoft is giving aren't impressive at all. From your link:
The following examples demonstrate possible savings from reboot reduction:
* Of the 22 updates that shipped for Windows Server 2003 RTM between April 2005 and August 2005, 15 of them required a reboot. Eight of these could have been hotpatched. This would have reduced the number of reboots by 53%.
* Of the 14 updates that shipped for Windows Server 2003 Service Pack 1 (SP1) prior to August 2005, ten of them required a reboot. Four of these could have been hotpatched. This would have reduced the number of reboots by 40%.
It seems to me, after some googling, that while Windows actually does have mechanisms to patch functions of the in-memory kernel and libraries, that what hotpatching means in the context of Windows is pretty much a normal upgrade without a reboot.
What's really amazing that since forever Unix systems have had a documented EINTR error condition for system calls, indicating that the system call was interrupted for whatever reason and you should retry the call. For whatever reason, practically no one checks for EINTR. I suppose Linux kernel developers decided that it was easier to make system calls uninterruptible than to use the documented EINTR mechanism and wait for everyone to fix their user level code.
You made my day.
like rebooting. It's really more of a hassle, which is why I always suspend. Actually, I generally -don't- reboot. And I don't care enough to go out of my way to reboot just because of a kernel update or something (like Windows users..except they're forced to reboot after n minutes, even). Now, my boot process is fast and all..well, the BIOS (as most of them ime) is slow as hell. And I have an external plugged in or an ipod, forget about it. If the latter is plugged in, it just won't boot (and it freezes, forcibly telling you to modify the boot priority..). Another reason why I really want Coreboot. BIOSes are just like any piece of closed-source software: in general, I'd say that it sucks. Now, you could argue and say "but..but...a BIOS doesn't _have_ bugs" and I would point you to a list of bugs that I can easily find in my BIOS in an hour or so. Those are just the ones I find! What about the ones that corrupt memory and all of that fun stuff (and yes. in fact, many...hm. I forget the name...it's the most common BIOS software, and not only is it shitty to navigate in/configure, the boot time slow, but it corrupts low-memory, and the kernel has to work around this).
Of course open-source software has bugs. But at least we admit it, and allow easy reporting/discussing with the developers themselves, even. For one, the vendor might not even know about the bugs..and there is _no_ way to report them. For two, if they do, they probably don't care, as long as your "computer works". Or as long as it only affects so many users.
It's like how microsoft/apple (well actually...iirc apple is a bit better at this)...don't want to admit that their software HAS bugs. Just so that they can say "wow, look at that. it's perfect". when in reality you are just ignorant to it's flaws.
Wow, I really got sidetracked.. :)
Please stop calling software "technology". Live change-overs should be a feature implemented into Linux distros, though, something I've wanted for a long time though my idea was on more of a complex Linux (the kernel) level, a 2nd kernel being able to start up along side an existing one, and then the live kernel passing off the necessary info and handling to it on all-the-fly. Something like that. :P
Anything is possible in software.
Promote true freedom - support standards and interoperability.
You apply kernel upgrades to DB production servers ???
To save costs, a lot of smaller shops run the web application server on the same hardware as the database server, but these are typically running PostgreSQL or Oracle MySQL instead of Oracle Database. When a flaw is discovered in the RDBMS or the kernel it's running on, how is it safe not to upgrade? Or are you claiming that all software should work around known, fixed RDBMS bugs at the application level instead of updating the database server?
how much time is spent starting BIOS and the kernel compared to starting "everything but init"?
More than zero.
That's not what I asked. True, the time to restart the BIOS and kernel is greater than zero. But what (positive) fraction of the restart time involves the BIOS and kernel? And does the nonzero cost of this time necessarily exceed the benefits of restarting, such as clearing out stale caches and the like?
You probably need a new IT manager.
Ogre Wedding Planners llc.