Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ksplice



On Sep 15, 2010, at 2:31 PM, Jerry Feldman wrote:
> 
> I agree, this was the consensus, but the OP was just looking for some
> outside guidance. IMHO, if there is no reason to reboot, then don't. In
> the very near future, we will be able to patch running kernels.

I'm not sold on Ksplice.  I see it as a solution looking for a problem.  If you're that concerned about uptime then you're running a high availability cluster.  That degree of redundancy gives you the ability to perform rolling updates across the cluster.  You can install and test your updates without any impact on your users.

Ksplice removes testing from the loop.  Without rebooting you have to take it on faith that the in-memory kernel matches the on-disk kernel, that the on-disk kernel and associated initrd actually works, and that the on-disk kernel in question is actually the one that gets loaded at boot.  I for one don't take anything on faith with my production systems.  I insist on seeing it work for real before signing off on the work.

--Rich P.









BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org