Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
dtprobed: make sure the daemon is restarted
Unfortunately relying on the presets and a %systemd_postun_with_restart to enable and restart dtprobed is not enough: older installations used %systemd_postun, so when we upgrade from one of those, the daemon is not restarted. The older installations themselves enabled and restarted it by hand. Presets take the burden of enabling from us, but not the burden of restarting: we still have to do that, and doing it in %postun is only good enough when this is the package being upgraded *from*. So forcibly restart it in %post (after %systemd_post installs its service files, etc). This does mean that reinstallations may restart the daemon twice, but this is harmless, and in any case only applies to OL8 and below: OL9 amortizes all restarts and does them in %posttrans. Doing this is tangled and ridiculous: the actual underlying method used to restart differs on OL8-and-before and on OL9+, but the %systemd_postun_with_restart macro does the right thing on both distros. Unfortunately because it's meant to run from %postun it checks for the wrong value of $1 (>= 1, meaning everything but install, while we want >= 2 which means the same thing in %post). So wrap the whole thing in a conditional to prevent it double-restarting on new installations. On OL8 and below we have another problem: the unit file has changed, but the systemd macros on OL8 and below don't reload it except on initial installation: and the change is essential because without it dtprobed doesn't have permission to write anything to /run/dtrace. So on OL7 and OL8, do a daemon-reload before restarting. The result appears to survive initial installation, upgrade from .12 and .13.1, and rpm --reinstall on both OL8 and OL9. While we're changing this, take out the mention of dtrace-usdt.target in %systemd_preun: as a .target, it's meaningless to restart it or do anything else %preun does to it, and naming it there causes horrible warning messages on uninstallation. Signed-off-by: Nick Alcock <nick.alcock@oracle.com> Reviewed-by: Kris Van Hees <kris.van.hees@oracle.com>
- Loading branch information