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 at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]