The unbound-libs package is depending on chronie, chronie-anacron and crontabs and thus dragging in extra dependencies that are not needed. Since unbound-libs is a dependency in other packages for example GnuTLS, there will be always cron files installed. The same task can be easily accomplished with a systemd timer unit. And unbound should use that instead. No need to drag in chronie for this.
Created attachment 983267 [details] migrate unbound-anchor to systemd timer Use systemd timer instead of cronjob. Also change period from monthly to daily – see #1180267 for rationale. --- unbound-anchor.service | 9 +++++++++ unbound-anchor.timer | 14 ++++++++++++++ unbound.cron | 3 --- unbound.service | 3 ++- unbound.spec | 25 ++++++++++++++++++------- 5 files changed, 43 insertions(+), 11 deletions(-) create mode 100644 unbound-anchor.service create mode 100644 unbound-anchor.timer delete mode 100644 unbound.cron
Thanks! We'll want to create an upstream patch. I recently ported dnssec-trigger systemd service files upstream and it will be good to get verything upstream also for unbound.
Available in F22+
Why the postinstall script of unbound-libs start unbound-anchor.timer? Even if the unbound-anchor.timer is disabled before updating the rpm, the timer is started after the update. I guess that 'timer' should be 'service'. If my guess is correct, I also have another question: why unbound-anchor runs twise in the postinstall script? The following two commands /usr/sbin/runuser --command="/usr/sbin/unbound-anchor -a /var/lib/unbound/root.anchor -c /etc/unbound/icannbundle.pem" --shell /bin/sh unbound ||: and /bin/systemctl start unbound-anchor.service >/dev/null 2>&1 || : seem almost equivalent for me. I guess that the postinstall script of unbound-libs should be as follows ---------------------- %post libs /sbin/ldconfig %systemd_post unbound-anchor.timer # the Unit is in presets, but would be started afte reboot /bin/systemctl start unbound-anchor.service >/dev/null 2>&1 || : ----------------------
Oops, sorry, two commands are different. So, please forget my second question. But still I think 'timer' should be 'service'. --------------------- %post libs /sbin/ldconfig %{_sbindir}/runuser --command="%{_sbindir}/unbound-anchor -a %{_sharedstatedir}/unbound/root.anchor -c %{_sysconfdir}/unbound/icannbundle.pem" --shell /bin/sh unbound ||: %systemd_post unbound-anchor.timer # the Unit is in presets, but would be started afte reboot /bin/systemctl start unbound-anchor.service >/dev/null 2>&1 || : ---------------------
(In reply to Yu Watanabe from comment #5) > Oops, sorry, two commands are different. So, please forget my second > question. > > But still I think 'timer' should be 'service'. > > --------------------- > %post libs > /sbin/ldconfig > %{_sbindir}/runuser --command="%{_sbindir}/unbound-anchor -a > %{_sharedstatedir}/unbound/root.anchor -c > %{_sysconfdir}/unbound/icannbundle.pem" --shell /bin/sh unbound ||: > %systemd_post unbound-anchor.timer > # the Unit is in presets, but would be started afte reboot > /bin/systemctl start unbound-anchor.service >/dev/null 2>&1 || : > --------------------- No, we want the timer to be started, so the unbound-anchor is run daily even until next reboot. There is no guarantee AFAIK that when the timer is started, the service file is run immediately, thus the explicit run of unbound-anchor. Also note that the unbound-anchor.service is Oneshot, meaning, that starting it instead of the timer would defeat the purpose of the timer unit (previously cron job). I tested the functionality before pushing and I got expected results, IOW the behavior should be the same as with the cron job.
I am afraid I may not understand well what the service do. However, if the service or timer is necessary to the system, why the timer is disabled and just started by the postscript? After updating the package, the timer is active, but disabled (because the system preset is disabled). I notice that the man page of unbound-anchor should be in the unbound-libs rpm. But this is off topic, sorry.
I also guess that unbound.service should be: ---------- After=unbound-anchor.timer Wants=unbound-anchor.timer ---------- 'unbound-anchor.service' should be 'unbound-anchor.timer'.
(In reply to Yu Watanabe from comment #8) > I also guess that unbound.service should be: > ---------- > After=unbound-anchor.timer > Wants=unbound-anchor.timer > ---------- > 'unbound-anchor.service' should be 'unbound-anchor.timer'. This may incorrect. sorry. I am very confusing...
(In reply to Yu Watanabe from comment #7) > I am afraid I may not understand well what the service do. However, if the > service or timer is necessary to the system, why the timer is disabled and > just started by the postscript? There is Bug #1215641 that is not yet fixed. The unbound-anchor.timer will be added to the system presets and thus will be enabled by default after installation. I could enable it manually in the SPEC file, but this would not comply to the Fedora Packaging Guidelines. > After updating the package, the timer is active, but disabled (because the > system preset is disabled). Will be enabled in the future. > I notice that the man page of unbound-anchor should be in the unbound-libs > rpm. > But this is off topic, sorry. (In reply to Yu Watanabe from comment #8) > I also guess that unbound.service should be: > ---------- > After=unbound-anchor.timer > Wants=unbound-anchor.timer > ---------- > 'unbound-anchor.service' should be 'unbound-anchor.timer'. This is good note. The After=unbound-anchor.service Wants=unbound-anchor.service are correct, but there should be also Wants on the timer unit, so it is started with unbound if not running already. I'll fix it.
(In reply to Tomas Hozza from comment #10) > There is Bug #1215641 that is not yet fixed. The unbound-anchor.timer will > be added to the system presets and thus will be enabled by default after > installation. OK. I did not know that. Thanks. > I could enable it manually in the SPEC file, but this would > not comply to the Fedora Packaging Guidelines. Yes. I agree.