[arch-general] systemd timers: switch default target to timers.target?
Hi everybody, It seems like systemd now provides a target that is intended to gather all timers supposed to be activated after boot. From man 7 systemd.special:
timers.target A special target unit that sets up all timer units (see systemd.timer(5) for details) that shall be active after boot. It is recommended that timer units installed by applications get pulled in via Wants= dependencies from this unit. This is best configured via WantedBy=timers.target in the timer unit's "[Install]" section.
systemd package itself provides two timers, /usr/lib/systemd/system/systemd-readahead-done.timer and /usr/lib/systemd/system/systemd-tmpfiles-clean.timer, the latter being statically enabled in the "new" /usr/lib/systemd/system/timers.target.wants directory. Five other packages in base group provide systemd timers: logrotate, man-db, mdadm, shadow and util-linux. I didn't manage to use pkgfile to get this list (globbing and regex switches didn't help, dunno why), so I only counted .timer files present in /usr/lib/systemd/system/. $ pacman -Qo /usr/lib/systemd/system/*.timer /usr/lib/systemd/system/fstrim.timer is owned by util-linux 2.25.1-1 /usr/lib/systemd/system/logrotate.timer is owned by logrotate 3.8.7-3 /usr/lib/systemd/system/man-db.timer is owned by man-db 2.6.7.1-1 /usr/lib/systemd/system/mdadm-last-resort@.timer is owned by mdadm 3.3.1-2 /usr/lib/systemd/system/shadow.timer is owned by shadow 4.2.1-1 /usr/lib/systemd/system/systemd-readahead-done.timer is owned by systemd 216-3 /usr/lib/systemd/system/systemd-tmpfiles-clean.timer is owned by systemd 216-3 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. Cheers, Neitsab
On Sat, Oct 4, 2014 at 1:44 PM, Neitsab <neitsab@ovh.fr> wrote:
Five other packages in base group provide systemd timers: logrotate, man-db, mdadm, shadow and util-linux. I didn't manage to use pkgfile to get this list (globbing and regex switches didn't help, dunno why), so I only counted .timer files present in /usr/lib/systemd/system/.
AFAICT, pkgfile can list packages from the file name or file names from the package, but not plain files by name. Anyway it can be piped with a bit of imagination: $ pkgfile --glob *.timer | xargs -n1 pkgfile --list | grep .timer$ /usr/lib/systemd/system/logrotate.timer /usr/lib/systemd/system/multi-user.target.wants/logrotate.timer /usr/lib/systemd/system/man-db.timer /usr/lib/systemd/system/multi-user.target.wants/man-db.timer /usr/lib/systemd/system/mdadm-last-resort@.timer /usr/lib/systemd/system/multi-user.target.wants/updatedb.timer /usr/lib/systemd/system/updatedb.timer /usr/lib/systemd/system/multi-user.target.wants/shadow.timer /usr/lib/systemd/system/shadow.timer /usr/lib/systemd/system/systemd-readahead-done.timer /usr/lib/systemd/system/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/timers.target.wants/systemd-tmpfiles-clean.timer /usr/lib/systemd/system/fstrim.timer /usr/lib/systemd/system/hylafax.timer /usr/lib/systemd/system/multi-user.target.wants/hylafax.timer /usr/lib/systemd/system/pkgfile-update.timer /usr/lib/systemd/system/multi-user.target.wants/pkgstats.timer /usr/lib/systemd/system/pkgstats.timer /usr/lib/systemd/system/mailman-checkdbs.timer /usr/lib/systemd/system/mailman-cullbadshunt.timer /usr/lib/systemd/system/mailman-disabled.timer /usr/lib/systemd/system/mailman-gatenews.timer /usr/lib/systemd/system/mailman-mailpasswds.timer /usr/lib/systemd/system/mailman-nightlygzip.timer /usr/lib/systemd/system/mailman-senddigests.timer /usr/lib/systemd/system/snapper-cleanup.timer /usr/lib/systemd/system/snapper-timeline.timer /usr/lib/systemd/system/squid-rotate.timer /usr/lib/systemd/system/timers.target.wants/squid-rotate.timer /usr/lib/systemd/system/sysstat-collect.timer /usr/lib/systemd/system/sysstat-summary.timer HTH
On 05/10/2014 20:21, Rodrigo Rivas wrote:
On Sat, Oct 4, 2014 at 1:44 PM, Neitsab <neitsab@ovh.fr> wrote: $ pkgfile --glob *.timer | xargs -n1 pkgfile --list | grep .timer$ /usr/lib/systemd/system/mailman-checkdbs.timer /usr/lib/systemd/system/mailman-cullbadshunt.timer /usr/lib/systemd/system/mailman-disabled.timer /usr/lib/systemd/system/mailman-gatenews.timer /usr/lib/systemd/system/mailman-mailpasswds.timer /usr/lib/systemd/system/mailman-nightlygzip.timer /usr/lib/systemd/system/mailman-senddigests.timer /usr/lib/systemd/system/snapper-cleanup.timer /usr/lib/systemd/system/snapper-timeline.timer /usr/lib/systemd/system/squid-rotate.timer
Mailman/squid timers depends on timers.target... -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
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.
On 06/10/2014 23:45, Thomas Bächler wrote:
Am 04.10.2014 um 13:44 schrieb Neitsab: 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.
Upstream recommends to stick to timers.target. If units should be delayed after others After= and Before= directives do the job. There is also OnBootSec= if you want to delay timers on a timed way. from (7) systemd.special: timers.target A special target unit that sets up all timer units (see systemd.timer(5) for details) that shall be active after boot. It is recommended that timer units installed by applications get pulled in via Wants= dependencies from this unit. This is best configured via WantedBy=timers.target in the timer unit's "[Install]" section. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Am 08.10.2014 um 02:51 schrieb Sébastien Luttringer:
On 06/10/2014 23:45, Thomas Bächler wrote:
Am 04.10.2014 um 13:44 schrieb Neitsab: 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.
Upstream recommends to stick to timers.target. If units should be delayed after others After= and Before= directives do the job. There is also OnBootSec= if you want to delay timers on a timed way.
I don't care what upstream recommends, there is no reason for this target to exist and there is no reason to use it. Things get even worse, since you cannot order the unit After=something - since timers.target pulls the unit, it gets an implicit ordering Before=timers.target, removing lots of flexibility with regards to ordering (since timers.target is before sysinit.target).
Thomas Bächler wrote in message <543579D1.4010902@archlinux.org>:
I don't care what upstream recommends, there is no reason for this target to exist and there is no reason to use it. Things get even worse, since you cannot order the unit After=something - since timers.target pulls the unit, it gets an implicit ordering Before=timers.target, removing lots of flexibility with regards to ordering (since timers.target is before sysinit.target).
I don't really care about timers.target, but shouldn't the dependency be put in the corresponding services files rather than in the timers? I personally see timers as similar to sockets files, essentially trivial to launch, all the work being done in the services files.
Am 08.10.2014 um 20:28 schrieb Damien Robert:
Thomas Bächler wrote in message <543579D1.4010902@archlinux.org>:
I don't care what upstream recommends, there is no reason for this target to exist and there is no reason to use it. Things get even worse, since you cannot order the unit After=something - since timers.target pulls the unit, it gets an implicit ordering Before=timers.target, removing lots of flexibility with regards to ordering (since timers.target is before sysinit.target).
I don't really care about timers.target, but shouldn't the dependency be put in the corresponding services files rather than in the timers? I personally see timers as similar to sockets files, essentially trivial to launch, all the work being done in the services files.
The point with sockets and paths has been made clear in the original systemd blog post: You first set up all socket and path units, then you can start all daemons in parallel without caring for ordering. That is why there is a strict ordering between sockets/paths and normal services. Timers fulfill no such requirement. They are supposed to be started whenever the init system can do it.
participants (5)
-
Damien Robert
-
Neitsab
-
Rodrigo Rivas
-
Sébastien Luttringer
-
Thomas Bächler