Am 04.10.2014 um 13:44 schrieb Neitsab: > Hi everybody, > > It seems like systemd now provides a target that is intended to gather > all timers supposed to be activated after boot. This target that systemd "now" provides has always been available. > Currently, three timers are statically enabled via symlinks in > /usr/lib/systemd/system/multi-user.target.wants/ after install > (logrotate.timer, man-db.timer and shadow.timer), while as already said > systemd-tmpfiles-clean.timer is statically enabled via a symlink in > /usr/lib/systemd/system/timers.target.wants/ (seemingly respecting new > practice). On the other hand, util-linux' fstrim.timer, when enabled via > systemctl, gets symlinked in /etc/systemd/system/multi-user.target.wants/. > > Other packages not part of base like extra/pkgstats or extra/mlocate > also provide timers that once enabled, get symlinked to > /usr/lib/systemd/system/multi-user.target.wants/. > > So AFAICT, there are quite some discrepancies concerning how systemd > timers are implemented. I'd like to discuss whether Arch should switch > default timers target for packages in base group from multi-user.target > to timers.target, possibly doing so for other packages in official repos. Why? Most of these timers should only be available when running a fully booted system. timers.target is pulled in by basic.target. This implies that startup of all normal services is delayed until the startup of these timers (and other units) has finished. This may make sense for socket or path units, but is entirely unnecessary for timer units, especially those that merely serve as cron replacements.
Attachment:
signature.asc
Description: OpenPGP digital signature
