On Tue, Sep 05, 2023 at 03:53:38PM +0200, Martin Lottermoser wrote: > Package: apt > Version: 2.6.1 > Severity: normal > Tags: patch > X-Debbugs-Cc: martin.lottermoser@htp-tel.de > > Dear Maintainers, > > the initial comments in apt.systemd.daily state: > > All of the n-days interval options also accept the suffixes > s for seconds, m for minutes, h for hours, d for days or > the "always" value to do the action for every job run, > which can be used with systemd OnCalendar overrides to > define custom schedules for the apt update/upgrade jobs. > > This strongly suggests that a granularity below one day is possible. > That, however, is false because the check_stamp() function in that file > converts the modification date of the time stamp file as well as the > current time by first moving each back to the next 00:00 hours in the > local timezone before comparing the two. That gives an effective > granularity of one day; in particular, the resulting difference > (calculated by the script in seconds!) may be incorrect by up to > 23 hours, 59 minutes and 59 seconds in either direction, an interval > of almost two days. > > No motivation is given for this shift to midnight and in addition > comments in the file state that the calculation might fail sometimes in > certain timezones. > > None of this seems necessary and the shifts should therefore be eliminated. > A proposed patch is attached which also removes two unnecessary "date" > calls used for recomputing the already-set variable "now". The reason it does what it does exists, the cron job runs once a day and if you compare the timestamps directly, and the cron job happens to run 23:59:59 hours after the last time, it wouldn't execute, hence it just compares the days. The other timestamps were contributed at a later point but not tested, only the 0 value was. I have no intention of changing the behavior of these timestamps because we really need to remove them entirely and rely on systemd.timer execution settings, otherwise this never works reliable (and the cron job for non-systemd systems will retain the existing behavior as-is, it is a static target that should remain bug-compatible forever). But this requires splitting up the services further to reasonable levels of configurability and I haven't put any work into that yet. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature