Ksplice

[jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org (Jarod Wilson)]

On Wed, Sep 15, 2010 at 2:56 PM, Richard Pieri <richard.pieri-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> 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.

Also not sold on Ksplice, despite having a discussion w/their CTO
about it a few months back. Neat trick, but what Rich said. And think
about it from your vendor's (Red Hat's) viewpoint, if you're running a
paid-support distro, like Red Hat Enterprise Linux... You're NOT
running Red Hat's official bits, you're running something that
resembles them, and if done right, *probably* runs the same as if you
were running the latest errata kernel that your ksplice patches were
extracted from... But not exactly. Modifying a live-running kernel can
never be the same as booting a new kernel in many cases, because some
code only gets run at boot time or device initialization time. Is Red
Hat supposed to support that mutant combo it hasn't vetted itself? I
think not.

The way I've heard it spun though is that its so you can apply
critical hotfixes on the fly, then boot the proper updated kernel when
its more convenient. So not really so much of an uptime thing, but a
convenience thing. If bringing your server(s) down during peak
business hours costs you tons of money and you can patch a critical
vulnerability on the fly, then reboot after hours, maybe its worth it,
dunno. But that goes back to the issue Rich brought up, where if
keeping the systems up is *that* critical, that you should have fully
redundant systems already, capable of handling rolling updates. Maybe
your main admin is away at a seminar and can only ssh in and apply the
hotfix now, and will do the full reboot later in the evening. Grasping
at straws here trying to find a reason I'd really want to use Ksplice
other than "because its a neat trick!".

-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org