Dag Wieers wrote:

On Thu, 4 May 2006, John Hinton wrote:

...

I have asked myself over the years... just what happens during the update process? For instance, the latest updates included updates to php. I'm wondering if apache is restarted or reloaded to read the new php updates?

More broadly... if this is done, is it done pretty much for every interrelated update, I guess with the exception of kernel updates?

You can inspect a package's scripts by doing:

rpm -q --scripts php

In this case (at least on rhel4as) apache is not restarted/reloaded.

Kind regards,

Thanks Dag!

So, my normal routine of manually restarting Apache after PHP updates is a good one to follow.

I do think though that this could be considered a bit of a hole. With automatic updates being pushed to the forefront... where updates might happen when you're not even at the machine.. one could easily miss this sort of thing. And, as many of my systems run at least as long as it becomes necessary to reboot due to a kernel issue that actually effects something I'm running... it could be a long time between an update and a service restart. This is sort of frustrating to some degree.

Now to figure out what might need to be restarted based on what is updated each time.. not such an easy task anymore with the huge number of packages and the interrelationships between those packages. Hmmmmm....

Thanks, John Hinton <who is about to restart apache on all our systems>

On Fri, 5 May 2006, John Hinton wrote:

Dag Wieers wrote:

...

On Thu, 4 May 2006, John Hinton wrote:

...

I have asked myself over the years... just what happens during the update process? For instance, the latest updates included updates to php. I'm wondering if apache is restarted or reloaded to read the new php updates?

More broadly... if this is done, is it done pretty much for every interrelated update, I guess with the exception of kernel updates?

You can inspect a package's scripts by doing:

rpm -q --scripts php

In this case (at least on rhel4as) apache is not restarted/reloaded.

Kind regards,

Thanks Dag!

So, my normal routine of manually restarting Apache after PHP updates is a good one to follow.

I do think though that this could be considered a bit of a hole. With automatic updates being pushed to the forefront... where updates might happen when you're not even at the machine.. one could easily miss this sort of thing. And, as many of my systems run at least as long as it becomes necessary to reboot due to a kernel issue that actually effects something I'm running... it could be a long time between an update and a service restart. This is sort of frustrating to some degree.

Now to figure out what might need to be restarted based on what is updated each time.. not such an easy task anymore with the huge number of packages and the interrelationships between those packages. Hmmmmm....

Much like changes made to a config-file a week before by someone else might prevent a server from starting at present.

It's absolutely important to be proactive when you work with service level agreements. But it can help a lot when even in case when things go wrong, you can act quickly to fix things.

So you really want to monitor every service (and component) and track changes to config-files to troubleshoot (root-cause analysis) with as little effort as possible.

For monitoring services you can use something like nagios or zabbix and make sure you are aware of problems before anyone else.

For tracking changes to a system you have lots of options, I use dconf as a tool that make snapshots at regular intervals (or on demand), other people manage systems with cfengine or even subversion.

Whatever works best for you and what doesn't add more overhead than it tries to remedy.

Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]