Hi all, I'm curious. If I do yum update (which include kernel update) but don't reboot. Is it OK? I mean apart of the kernel, other things like services, we don't have to reboot if we don't have the chance to do it (postponing to some other date), right?
Thank you.
Hi Fajar,
usually you're fine, although i experienced some kind of "binary rot" if I did that too excessively. Especally things that are located "near" the kernel like initscripts and the xen daemon may start acting funny (like domU not starting up any more and such things...) if the kernel version is too far off.
I'm curious. If I do yum update (which include kernel update) but don't reboot. Is it OK? I mean apart of the kernel, other things like services, we don't have to reboot if we don't have the chance to do it (postponing to some other date), right?
At Fri, 25 Mar 2011 18:15:38 +0800 CentOS mailing list centos@centos.org wrote:
Hi all, I'm curious. If I do yum update (which include kernel update) but don't reboot. Is it OK? I mean apart of the kernel, other things like services, we don't have to reboot if we don't have the chance to do it (postponing to some other date), right?
Yes, you only *need* to reboot to pick up a new kernel. Unlike MS-Windows, none of the other updates *require* a reboot. Note: if glibc (or other widely used shared libraries) is updated it (they) won't get picked up unless *ALL* of the processes that use it (them) are restarted.
Thank you. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, Mar 25, 2011 at 06:59:26AM -0400, Robert Heller wrote:
Yes, you only *need* to reboot to pick up a new kernel. Unlike MS-Windows, none of the other updates *require* a reboot. Note: if
Warning, though: there's a big difference between *need* and *should*.
glibc (or other widely used shared libraries) is updated it (they) won't get picked up unless *ALL* of the processes that use it (them) are restarted.
Other changes may only take effect once a reboot occurs. In other cases you may end up with some programs using new setting and others using old settings (eg tzdata; if you've just had a new daylight-savings rule change then updating your tzdata rpms will cause newly started programs to use the new rules, but old programs to still use the old). It's not just limited to glibc.
So, depending on the packages being updated, I normally _recommend_ a reboot. But, being a sensible OS, you can reboot at the time of your choosing, not at patch time :-)
At Sun, 27 Mar 2011 07:56:19 -0400 CentOS mailing list centos@centos.org wrote:
On Fri, Mar 25, 2011 at 06:59:26AM -0400, Robert Heller wrote:
Yes, you only *need* to reboot to pick up a new kernel. Unlike MS-Windows, none of the other updates *require* a reboot. Note: if
Warning, though: there's a big difference between *need* and *should*.
Oh, quite understood.
glibc (or other widely used shared libraries) is updated it (they) won't get picked up unless *ALL* of the processes that use it (them) are restarted.
Other changes may only take effect once a reboot occurs. In other cases you may end up with some programs using new setting and others using old settings (eg tzdata; if you've just had a new daylight-savings rule change then updating your tzdata rpms will cause newly started programs to use the new rules, but old programs to still use the old). It's not just limited to glibc.
So, depending on the packages being updated, I normally _recommend_ a reboot. But, being a sensible OS, you can reboot at the time of your choosing, not at patch time :-)
Yes, definately.
Hi all, I'm curious. If I do yum update (which include kernel update) but don't reboot. Is it OK? I mean apart of the kernel, other things like services, we don't have to reboot if we don't have the chance to do it (postponing to some other date), right?
On the topic of updating the kernel w/o rebooting, there is this:
I've heard of it, but never used it. Curious to hear other people's experiences...
Cheers
Steve
On 03/25/2011 11:17 AM, Steve Barnes wrote:
http://www.ksplice.com/I've heard of it, but never used it. Curious to hear other people's experiences...
I have met and spoken at length with the ksplice guys - its really cool stuff, and they are a great bunch of guys. If you do consider to use it, remember to ask them to make the centos kernel patches available publicly!
Also worth noting is that the toolchain for ksplice is open source, and everything needed to make the patches is available. So if there is interest and a couple of people want to help make it happen, we can do something within the centos ecosystem.
- KB
On 03/25/2011 11:17 AM, Steve Barnes wrote:
http://www.ksplice.com/I've heard of it, but never used it. Curious to hear other people's experiences...
I have met and spoken at length with the ksplice guys - its really cool stuff, and they are a great bunch of guys. If you do consider to use it, remember to ask them to make the centos kernel patches available publicly!
Also worth noting is that the toolchain for ksplice is open source, and everything needed to make the patches is available. So if there is interest and a couple of people want to help make it happen, we can do something within the centos ecosystem.
- KB
I'd certainly be in support of such a facility within CentOS, but before I raise my hand as a volunteer I should probably ask - what would be involved?
The fact that I have to ask that question in the first place may, in itself, be sufficient evidence that I'm not the right person for the job, but I figure I'd ask anyway.
More than happy to start the process of learning if someone can point me in the right direction...or just test stuff for others more suited to getting the project off the ground :)
Cheers
Steve
On 03/25/11 3:15 AM, Fajar Priyanto wrote:
Hi all, I'm curious. If I do yum update (which include kernel update) but don't reboot. Is it OK? I mean apart of the kernel, other things like services, we don't have to reboot if we don't have the chance to do it (postponing to some other date), right?
the longer you put off that reboot, the harder it will be to fix if something does go wrong, unless you are meticulous about keeping notes on each and every change.
John R Pierce wrote:
On 03/25/11 3:15 AM, Fajar Priyanto wrote:
Hi all, I'm curious. If I do yum update (which include kernel update) but don't reboot. Is it OK? I mean apart of the kernel, other things like services, we don't have to reboot if we don't have the chance to do it (postponing to some other date), right?
the longer you put off that reboot, the harder it will be to fix if something does go wrong, unless you are meticulous about keeping notes on each and every change.
Well, within limits. If there's a kernel update that fixes a bug, or security hole that only affects this NIC, or that OEM hardware bug, and you don't have either, then it's a moot point. The ones you *really* want to reboot after are ones that directly affect the hardware and software you're running, and, if you have users, you want to schedule the reboot (aka "maintenance window"). The others, we've waited two and three kernels before we decided to do the reboot. Lessee, 2.6.18-194-11.4, I think, was important to us, but those since have been no big deal. Most of our systems have been rebooted to the current kernel, but not all.
(Ah, the joys of getting buyin from the managers of a monthly maintenance window: no more begging, pleasding, and waiting for days or weeks to do the reboot, or apache restart, or.... And yes, we are a high perfomance computing center, and some folks *do* have jobs that run for days or even weeks....)
mark "then there are the ones who were antsy about *any* update that might break their (fragile, IMO) packages..."
Slightly OT, but I have more than one pacemaker/corosync cluster where one of the main reasons to use a cluster (in addition to the availability aspect) is to be able to perform running updates without affecting the user base. As in:
1. All services running on node A. 2. Update node B. 3. Cut services over to node B. 4. Test services. 5. Update node A. 6. Cut services back to node A. 7. Test services.
In these particular cases, it was deemed acceptable that the time to cut a service over from one node to another did not require a special maintenance window (including the time to revert back to the non-updated node should there be a problem with the update). Thus, we're able to apply updates at our leisure and not end up with a long time between update and reboot.
It sure makes keeping a production system current a whole lot easier.
(Depending on the service, cutover times range from about 5-60 seconds per service).
Devin
-
Devin Reade -
Fajar Priyanto -
John R Pierce -
Karanbir Singh -
m.roth＠5-cent.us -
Robert Heller -
Stephen Harris -
Steve Barnes -
Thomas Göttgens