Control: reassign -1 systemd Control: affects -1 + apt-listbugs Control: tags -1 - moreinfo
On Wed, 15 Jul 2020 10:49:16 +0200 Oswald Buddenhagen wrote: > On Tue, Jul 14, 2020 at 10:51:06PM +0200, Francesco Poli wrote: > >Do you mean that your "no network when apt-listbugs timer runs" only > >happens immediately after a wake-up from a suspended state and only > >when the system has had no chance to run the timer between 7:00 a.m. > >and the wake-up itself? > > > yes [...] OK, after researching a bit more about systemd timers, I think this is a bug in systemd. I am consequently reassigning your bug report to package systemd. Dear Debian systemd maintainers, please let me describe the issue experienced by Oswald (user of package apt-listbugs). Package apt-listbugs (of which I am the maintainer) ships the following timer unit: $ cat /lib/systemd/system/apt-listbugs.timer # This file is part of apt-listbugs # # Copyright (C) 2019 Francesco Poli <invernom...@paranoici.org> # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License with # the Debian GNU/Linux distribution in file /usr/share/common-licenses/GPL-2; # if not, write to the Free Software Foundation, Inc., 51 Franklin St, # Fifth Floor, Boston, MA 02110-1301, USA. [Unit] Description=Daily apt-listbugs preferences cleanup After=network.target network-online.target [Timer] OnActiveSec=5min OnCalendar=*-*-* *:20 RandomizedDelaySec=20min [Install] WantedBy=timers.target The goal here is to have the corresponding (Type=oneshot) service unit executed 5 min after the activation of the timer unit and hourly, with a random delay between 0 and 20 min, and anyway after the network link is available and working. The service unit should *not* catch up with missed executions (the timer has no Persistent=true directive). I think the above directives are the ones needed to achieve the stated goal. And they seem to work correctly after boot (when at least 5 min and at most 25 min are waited, before triggering the service) and during normal operation (when the service is triggered hourly with a delay between 0 and 20 min). On the other hand, the original bug reporter (Oswald) sees that the service is triggered immediately after each wake-up from sleep. Before the network has had a chance to become available and working. Please take a look at the bug log, especially [message#37], which include a log of the wake-up. [message#37]: <https://bugs.debian.org/964438#37> I think this is a bug in systemd. If this is the case, please investigate/fix the issue and/or forward my bug report upstream, as appropriate. Otherwise, please tell me what's wrong in the timer unit, as I cannot really figure it out by myself, despite several attempts to find the answer in the documentation or on the web... :-( Thanks for your time and for any help you may provide! Bye. -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpdyWym6myOV.pgp
Description: PGP signature
