-----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-----