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
