Warren, thank you very much for the info! I learned a lot.

On 4/9/09, Warren Young warren@etr-usa.com wrote:

nate wrote:

...

Jerry Geis wrote:

...

What is the rule of thumb for reboots after updates...

only with new kernels.

...and then only when you want what the new kernel provides.

I have my systems configured so yum is allowed to download and install new kernels, but don't usually reboot unless I want the specific thing the new kernel fixed, or have to reboot for some other reason. This saves me some hassle in rebuilding third-party drivers.

Windows boxes have to reboot on almost every upgrade because the file I/O semantics don't allow replacing files that are in use, except in some very limited cases. Windows has a feature that *ix type boxes don't need, which is that a program can schedule a file to be replaced on the next reboot. It's part of the "move file" API. Installers do this when they try to replace a file and fail, which is why an installer might not always prompt for a reboot on completion; it depends on whether the program was running when you ran the installer. This is also why so many Windows installers demand that you shut everything else down while you install the program. They're trying to help you out.

I bring this seemingly off-topic thing up here because it's why a lot of people get the idea that upgrades mean reboots. It simply isn't usually needed in the *ix world. It's why my uptime records for *ix boxes are over a year, while my Windows boxes rarely stay up for a full month and almost never beyond that due to Patch Tuesday. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

At Thu, 09 Apr 2009 10:38:08 -0500 CentOS mailing list centos@centos.org wrote:

Robert Heller wrote:

...

At Thu, 09 Apr 2009 07:49:30 -0400 CentOS mailing list centos@centos.org wrote:

...

What is the rule of thumb for reboots after updates...

Certainly if I update from 5.2 to 5.3 I reboot.

But if you update something like krb5 or pam does that require a reboot? Does the "fix" get automatically loaded and used or do you just do a reboot always?

You only *really* need to reboot if/when you update the kernel. Yum/RPM takes care of restarting daemons, etc. during the update process. This is NOT MS-Windows....

Yes, but any program that is already running will keep using the old versions of the program, libraries, open files, etc., retaining the disk space and not sharing the in-memory copy with new instances that start after the update. And since modern programs like to dynamically load library modules as needed while running you can get a strange mix of old/new versions running at once.

Generally, this is not as bad as it seems. In some cases, some updates do restart critical daemons (rpm -hUv glibc... will restart sshd for example). Also, since most critical library updates also imply a similar update for the deamons/programs that use those libraries and since the rpms for the deamon programs do restart the deamon they install/update, in most cases the deamons do get restarted at some point during the update process -- that is, since httpd (Apache) depends on apr and when apr gets a critical update, it is very likely that the httpd program would also be rebuilt as well, so that both rpms are updated in the repo. A 'yum update' will install the new apr rpm, then the new httpd rpm and at that point restart httpd, this picking up the new apr library.

Scott Silva wrote:

...

...

...

You only *really* need to reboot if/when you update the kernel. Yum/RPM takes care of restarting daemons, etc. during the update process. This is NOT MS-Windows....

Yes, but any program that is already running will keep using the old versions of the program, libraries, open files, etc., retaining the disk space and not sharing the in-memory copy with new instances that start after the update. And since modern programs like to dynamically load library modules as needed while running you can get a strange mix of old/new versions running at once.

Generally, this is not as bad as it seems. In some cases, some updates do restart critical daemons (rpm -hUv glibc... will restart sshd for example). Also, since most critical library updates also imply a similar update for the deamons/programs that use those libraries and since the rpms for the deamon programs do restart the deamon they install/update, in most cases the deamons do get restarted at some point during the update process -- that is, since httpd (Apache) depends on apr and when apr gets a critical update, it is very likely that the httpd program would also be rebuilt as well, so that both rpms are updated in the repo. A 'yum update' will install the new apr rpm, then the new httpd rpm and at that point restart httpd, this picking up the new apr library.

Sometimes you just have to know your system. Like if you update a sendmail milter, you would need to restart sendmail also, but if the rpm developer didn't write that into the %post section you would want to do it yourself.

You have some chance of 'knowing' the server side of things - a lot less about what other users might be running. What should you expect if you have logged in users over freenx, remote X or at the console running (say) firefox through an update? Or other long running applications, especially in languages likely to dynamically load new components.

And in one case, I got kicked off of my ssh connection in mid-update. I'm still not sure what happened there but I had to install yum-utils and run yum-recover-transaction to continue.

on 4-9-2009 10:07 AM Les Mikesell spake the following:

Scott Silva wrote:

...

...

...

...

You only *really* need to reboot if/when you update the kernel. Yum/RPM takes care of restarting daemons, etc. during the update process. This is NOT MS-Windows....

Yes, but any program that is already running will keep using the old versions of the program, libraries, open files, etc., retaining the disk space and not sharing the in-memory copy with new instances that start after the update. And since modern programs like to dynamically load library modules as needed while running you can get a strange mix of old/new versions running at once.

Generally, this is not as bad as it seems. In some cases, some updates do restart critical daemons (rpm -hUv glibc... will restart sshd for example). Also, since most critical library updates also imply a similar update for the deamons/programs that use those libraries and since the rpms for the deamon programs do restart the deamon they install/update, in most cases the deamons do get restarted at some point during the update process -- that is, since httpd (Apache) depends on apr and when apr gets a critical update, it is very likely that the httpd program would also be rebuilt as well, so that both rpms are updated in the repo. A 'yum update' will install the new apr rpm, then the new httpd rpm and at that point restart httpd, this picking up the new apr library.

Sometimes you just have to know your system. Like if you update a sendmail milter, you would need to restart sendmail also, but if the rpm developer didn't write that into the %post section you would want to do it yourself.

You have some chance of 'knowing' the server side of things - a lot less about what other users might be running. What should you expect if you have logged in users over freenx, remote X or at the console running (say) firefox through an update? Or other long running applications, especially in languages likely to dynamically load new components.

And in one case, I got kicked off of my ssh connection in mid-update. I'm still not sure what happened there but I had to install yum-utils and run yum-recover-transaction to continue.

I always run my updates through screen. That way disconnects aren't a problem. During major updates I also usually run yum with the --downloadonly option so I can have most of the files local when I am ready.

On Thu, Apr 9, 2009 at 2:10 PM, Les Mikesell lesmikesell@gmail.com wrote:

I had done the --downloadonly - and the disconnect wasn't network related as other connections to the same site stayed up.  It seemed like something in the cleanup pass killed sshd - and the running yum, leaving a mess.  The transaction recovery list was mostly erasing the old packages.   But, this only happened on one machine out of many upgraded in exactly the same way so I don't really understand it.

--   Les Mikesell    lesmikesell@gmail.com

Sounds like something else interfered. I wouldn't blame this on updating.

But yeah: screen. I used to write database update scripts that would refuse to run unless the user was running in a screen session.

Les Mikesell wrote:

And in one case, I got kicked off of my ssh connection in mid-update. I'm still not sure what happened there but I had to install yum-utils and run yum-recover-transaction to continue.

That's why I use screen for remote updates.

Mike A. Harris wrote:

Jerry Geis wrote:

...

What is the rule of thumb for reboots after updates...

I'd say the rule of thumb is to do whatever works best for you, and that you'll likely get quite the variety of different responses. ;o)

...

Certainly if I update from 5.2 to 5.3 I reboot.

But if you update something like krb5 or pam does that require a reboot? Does the "fix" get automatically loaded and used or do you just do a reboot always?

If the kernel gets updated, obviously it goes without saying that you need to reboot for that. Also for 'init', or any of its dependencies.

Never for 'init'. Updates to 'init' will invoke "init q", which tells the running 'init' process to re-exec itself.

On Thu, Apr 9, 2009 at 10:55 PM, D Tucny d@tucny.com wrote:

2009/4/10 Mike A. Harris mharris@mharris.ca

...

Jerry Geis wrote:

...

What is the rule of thumb for reboots after updates...

I'd say the rule of thumb is to do whatever works best for you, and that you'll likely get quite the variety of different responses.  ;o)

...

Certainly if I update from 5.2 to 5.3 I reboot.

But if you update something like krb5 or pam does that require a reboot? Does the "fix" get automatically loaded and used or do you just do a reboot always?

So, I would say "reboot" is the simplest, safest, foolproof way to ensure you're running updates even if some people will balk at the idea that you have to reboot a Linux system.  You don't have to of course, but life is short and rebooting is fast.  ;o)

Another good reason to do a controlled reboot every now and again is to make sure that everything you expect to come back up does come back up, which can save you being woken up in the middle of the night if an uncontrolled reboot happens :)

And if one does a scheduled reboot, best to be there, so you can touch the box and best to do it when there is very low traffic. I remember advising that updates were available for IPCop last year. Scott Silva wrote that he would do it on a Sunday, when the big bosses weren't there. Sure enough, his IPCop box failed to reboot..... I'm doing the first update, from CentOS 5.2 (32 bit) to 5.3 now.