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.

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

Checking TUV's docs Deployment_Guide-en-US/ch-security-updates.html
section: '41.5.1.5. Applying the Changes' it looks like they expect
manual action to restart relevant stuff... and don't even give very
good advice...

e.g.
  Shared Libraries
...
  To determine which running applications link against a particular
  library, use the lsof command as in the following example:

   lsof /usr/lib/libwrap.so*

  This command returns a list of all the running programs which use
  TCP wrappers for host access control. Therefore, any program listed
  must be halted and relaunched if the tcp_wrappers package is
  updated.
...

which misses the point that lsof (etc) will be unable to look for
processes using libs which are deleted (e.g. by an update).

The (evil) code we already have for checking /proc/*/maps may (partly)
work but in tests on one of our SL4 systems that is fooled by prelink
being run on the libs (since that also replaces the files).  I assume
that I'd have a similar problem on SL5 though I could always turn off
prelink.

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.

I suppose we could run 'yum check-update' and parse the output to get
a list of package we can check against a 'reboot' list etc, but the
output looks a bit tedious...  Maybe I need a custom plugin  :-)

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

Though that is for an explicitly configured set of patterns...

 -- Jon