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."
Slight motto change:
Free as in prostitute.
Remember to maintain your supply of
"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?
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.
Some non-free commercial software runs on linux.
... 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.
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
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.
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).
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.
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.
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.
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.
I've always been told by the Linux fan-bois that they haven't rebooted their computers since 1847
It's like this, the first time you turn it on, it's called a "boot". Every time after that is called a "re-boot". If you've only had to turn it on once, you've never rebooted it.
The higher the technology, the sharper that two-edged sword.
Or you're running VMS. The Irish national railway had a cluster uptime of 17 years back in 2007 when VMS turned 30 =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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_.
Oh, that VMS stuff had been patched, and the hardware failures were taken care of too, I doubt any single cluster node had an uptime of more than 5-8 year =) It's precisely because they were designed around online patching, node failover, etc that such a feat could be accomplished. Of course the patching probably wasn't as time critical as a modern system that has to deal with the entire world of zero day exploits so things were probably much more rigorously tested then they can be today.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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.
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.