Thanks for the quick response. Answers interspersed below. On Fri, Apr 30, 2021 at 2:47 PM Francesco Poli <invernom...@paranoici.org> wrote: > > Control: tags -1 + moreinfo > > > On Fri, 30 Apr 2021 10:46:04 -0700 Ross Boylan wrote: > > [...] > > Dear Maintainer, > > Hello Ross, > thanks for your bug report. > > > > > It would be nice to clean up this minor annoyance before buster's release. > > I am afraid that we are too late for *buster* release. > Maybe you meant *bullseye*?!? ;-)
Yes. > Anyway, it's late for bullseye, as well: Debian testing is already in > hard freeze... > > But I don't think there's anything really in need for a fix. > Please read on. > > > > > * What led up to the situation? > > > > Installed apt-listbugs and logcheck on a debian testing system. > > Every *hour* I get email from logcheck that includes lines like this: > > Apr 30 08:37:06 debtest systemd[1]: Starting Daily apt-listbugs > > preferences cleanup... > > Apr 30 08:37:06 debtest systemd[1]: Finished Daily apt-listbugs > > preferences cleanup. > > (Obviously logcheck and the email are incidental; the point is the > > "Daily" cleanup is actually run hourly. However, the emails are > > part of why I find it annoying.) > > Does logcheck send e-mail messages for all the other systemd timers? > > As you may already know, you can get a list of active systemd timers on > your box with the following command: > > $ systemctl list-timers > Thanks for the tip; I wasn't familiar with list-timers. There are 11 on my list, but the only things I see in my hourly reports from logcheck were apt-listbugs and complaints about time synchronization. Of course, I don't know how many of the timers are hourly. Note the time sync messages reflect a real problem, and so seem appropriate. I do get occasional messages reflecting successful runs, e.g., Apr 30 23:15:11 debtest systemd-timesyncd[38257]: Timed out waiting for reply from 192.168.1.10:123 (192.168.1.10). Apr 30 23:49:30 debtest systemd-timesyncd[38257]: Timed out waiting for reply from 192.168.1.10:123 (192.168.1.10). May 1 00:00:01 debtest systemd[1]: Starting exim4-base housekeeping... May 1 00:00:01 debtest systemd[1]: Starting Daily man-db regeneration... May 1 00:00:01 debtest systemd[1]: Finished exim4-base housekeeping. > > > > * What exactly did you do (or not do) that was effective (or > > ineffective)? > > > > Investigated why this is happening. The package has an entry in > > /etc/cron.daily, which seems correct. But it also has > > /lib/systemd/system/apt-listbugs.timer which includes > > OnCalendar=*-*-* *:20 > > I believe this is telling it to trigger something at 20 minutes > > after the hour for every hour. There is also > > RandomizedDelaySec=20min > > in the same file, which may explain why it seems to run between 20 > > and 40 minutes after the hour for me. > > Yes, that is correct. > Please read bug [#932995] for a more detailed discussion about the same > surprise you experienced. Ah, I see: it's running, but it's mostly not *really* running (i.e., check but no update). > > [#932995]: <https://bugs.debian.org/932995> > > > > > This seems more like a task for anacron for systems that may not be > > up all the time, but I don't know enough about systemd to be sure > > how to turn it off, or if it can handle these situations. > > If you use systemd as your init system (PID 1), please do not turn it > off. It's the only apt-listbugs cleanup routine running, since the > cron.daily job does nothing, if systemd is PID 1. Good to know. It's a standard bullseye install, and so systemd is in control. > > > > > * What was the outcome of this action? > > Only observations so far, and so no change. I might change to > > OnCalendar=*-*-* 20:20 > > which I think means run at 8:20pm every day. But the VM is not up > > all the time and so that might miss some times it should run, > > unless the /etc/cron.daily/ entry acts as a safety net. > > That is exactly the reason why the cleanup is attempted hourly, but > performed at most once a day. > Again, see [#932995] for an explanation. > > > > > * What outcome did you expect instead? > > That a daily cleanup job would only run once a day. > > That's already happening: the cleanup runs at most once a day. > I tried this modification to apt-listbugs.timer: [Timer] OnActiveSec=5min #OnCalendar=*-*-* *:20 OnUnitActiveSec=23h 50m RandomizedDelaySec=20min which did fix the "running every hour" problem (even if the run is only to check if a real update is necessary). But this does not entirely meet the desired behavior expressed in 932995: 1) The "anniversary" time will be whenever the system started, not early AM if available. 2) At least with the current script, which just checks if it should run, the result could be as much as a 48 hour delay between real updates. This would happen if the system was turned on just under 24 hours from the previous real update. As I understand it, the script would determine it was too soon to run. The next chance would be 24 hours later. > > > > Another work-around for the visible annoyance would be for me to tell > > logcheck to ignore the relevant messages. > > I think this should be the way to avoid the annoyance. It avoids the annoyance of seeing the message, but it leaves the job firing every hour. > I am not knowledgeable enough about logcheck to help you in this. > Sorry about that. > > > > > Thanks for your work on the package:) > > You're welcome, I try to do my best... > > If you do not object, I will close this bug report. > I suppose, though, as observed in the other bug you mentioned, the message about "daily update" is confusing. The fact that other packages aren't exhibiting such behavior suggests there is some other way to handle this, but I certainly don't know what it is. Ross
