-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Peatfield wrote: > I was hoping that this would be 'simple' in that there was an obvious > place to point me at the notes on what magic is done. > > Considering the case of an update to 'openssl', there are many > packages which depend on it, and several of these have > services/daemons. > > However, as far as I can tell none of them have any obvious > '--scripts' or '--triggers' which will cause those to be re-started > if openssl is updated. Given RPM's current design, I'm unsure whether managing service restarts should be a decision made by an RPM packager. RPMs are far too free form in what they permit you to do, or not do. This can be clearly seen in your openssl example and contrasted with your ssh example below. At this point in time, I think it makes sense to use a configuration management tool (puppet, cfengine, bcfg2, smartfrog, etc) to manage service restarts following a package upgrade. Some of these tools manage relationships between packages/services better than others. > E.g. looking at the scripts/triggers for openssh-server exim and authd > I can't see how anything knows to trigger them to restart. > > Updating (e.g.) openssh-server will cause a restart of sshd 'cos the > script does that. It won't kill off existing running children, but > that kind of thing is usually sufficient to close down problems -- at > least ones which external people could trigger. I imagine/hope that > most packages containing services will do something similar... This issue of some rpms doing the necessary magic and others not doing so was the subject ([Config-mgmt] packages too?) of a recent discussion on the Config-mgmt list (http://lopsa.org/pipermail/config-mgmt). Part of that discussion centered around issues with RPM's current design and whether or not having %pre and %post scripts was a "good thing" to have in RPMs. This ties in with the recent interest in refactoring RPM to make some positive code changes to the code base. > Many years ago we used to decide (after testing on a small set of > machines) for each package-update if we needed to reboot after > applying the update. > > The hacks to look for deleted shared-libs etc was an attempt to avoid > some reboots, and at least partly automate the decision. If you have found a way to at least partly automate this process, I think you are ahead of what most shops are doing. I also imagine this process is pretty messy given the lack of standardization in package behaviour. > Googling finds at least one plugin which is designed to restart > service X if package Y is updated: > > https://lists.dulug.duke.edu/pipermail/yum-devel/2007-February/003143.html > https://lists.dulug.duke.edu/pipermail/yum-devel/2007-February/003157.html Again, this is something that is attainable with current config management tools, but it still seems to require a fair bit of brittle static configuration. I would love to see a more flexible/dynamic method for managing package/service dependencies. Looking forward, perhaps it would be possible to incorporate a framework, into the package management system, for dynamically determining service restart requirements just prior to package installation. My vote would be to remove dynamic behavior from RPM and instead move it into a tool such as YUM. Perhaps this would require that a YUM repository compile additional metadata about the RPMs it contains so that the installation tool has more data to work with to locate and resolve dependencies. - -- Mason Schmitt Systems Administrator Sunwave Cable Internet / Shuswap Internet Junction ph: (250) 832-9711 www.sunwave.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQKecbip6upg8pq8RAjJfAJ4knfgtV/SnGo9M6b+PJHjG1dsjKQCfctUd Oadq60ue7CRJHo81fusRxaU= =3C0Z -----END PGP SIGNATURE-----