guys, are you serious? it's fine that you document a dependency on a
missing systemd feature for a clean solution (if you actually file a
request upstream), but the bug is nonetheless in the current
implementation of the apt-listbugs package, and can be worked around
there (e.g., by polling
On Fri, 29 Jan 2021 18:33:23 +0100 Michael Biebl wrote:
> On Mon, 27 Jul 2020 23:26:52 +0200 Francesco Poli
> wrote:
> >
> > But there must be a way to set a timer that does *not* catch up with
> > missed runs, during both downtime and sleep time!
> >
> > If there isn't, then I would call this
So, as said, afaics, everything is working as documented.
If you want to see the behaviour changed, please raise this upstream.
This is not going to be something we implement downstream.
Regards,
Michael
signature.asc
Description: This is a digitally signed message part
On Sun, 26 Jul 2020 23:43:53 +0200 Michael Biebl wrote:
> Am 26.07.20 um 23:20 schrieb Francesco Poli:
[...]
> > If this is confirmed, then maybe the bug is exactly that the Persistent
> > directive does not apply to sleeping time (only to down time).
>
> I don't consider that a bug. Persistent
Am 26.07.20 um 23:12 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote:
>
>> Am 26.07.20 um 22:43 schrieb Francesco Poli:
>>> On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
>>>
>>> [...]
Afaics, the problem is, that your service does not properly
Am 26.07.20 um 23:12 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote:
>
>> Am 26.07.20 um 22:43 schrieb Francesco Poli:
>>> On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
>>>
>>> [...]
Afaics, the problem is, that your service does not properly
Am 26.07.20 um 23:20 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:49:06 +0200 Michael Biebl wrote:
>
>> Am 26.07.20 um 22:38 schrieb Francesco Poli:
>>> On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
> [...]
Persistent=true is relevant when you
reboot/power down a system.
On Sun, 26 Jul 2020 22:48:18 +0200 Michael Biebl wrote:
> Am 26.07.20 um 22:43 schrieb Francesco Poli:
> > On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
> >
> > [...]
> >> Afaics, the problem is, that your service does not properly handle the
> >> case, when the network is not
On Sun, 26 Jul 2020 22:49:06 +0200 Michael Biebl wrote:
> Am 26.07.20 um 22:38 schrieb Francesco Poli:
> > On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
[...]
> >> Persistent=true is relevant when you
> >> reboot/power down a system. In your case, the system is suspended and
> >> woken
Am 26.07.20 um 22:51 schrieb Michael Biebl:
> Am 26.07.20 um 22:38 schrieb Francesco Poli:
>
>> This is why I think the bug is in systemd.
>
> If you are convinced, this is an issue within systemd, then you'll need
> to take this upstream yourself as I clearly don't see the issue and can
> argue
Am 26.07.20 um 22:38 schrieb Francesco Poli:
> This is why I think the bug is in systemd.
If you are convinced, this is an issue within systemd, then you'll need
to take this upstream yourself as I clearly don't see the issue and can
argue the case for you.
signature.asc
Description: OpenPGP
Am 26.07.20 um 22:38 schrieb Francesco Poli:
> On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
>
>> Am 26.07.20 um 21:36 schrieb Francesco Poli:
> [...]
>>> Dear Michael,
>>> I am still convinced that this is a bug in systemd, as explained above.
>>> I am reassigning back the bug report
Am 26.07.20 um 22:38 schrieb Francesco Poli:
> Yet, the timer triggers during each wake-up, without waiting.
Wait for what?
signature.asc
Description: OpenPGP digital signature
On Sun, 26 Jul 2020 22:22:55 +0200 Michael Biebl wrote:
[...]
> Afaics, the problem is, that your service does not properly handle the
> case, when the network is not available.
It does, that's the reason why the operation is attempted hourly.
> Even if systemd would delay timer events after a
On Sun, 26 Jul 2020 22:06:23 +0200 Michael Biebl wrote:
> Am 26.07.20 um 21:36 schrieb Francesco Poli:
[...]
> > Dear Michael,
> > I am still convinced that this is a bug in systemd, as explained above.
> > I am reassigning back the bug report to package systemd.
> >
> > If you think that the
Am 26.07.20 um 22:06 schrieb Michael Biebl:
>> If you think that the timer unit can be modified so that it behaves as
>> intended, please tell me how I should modify it.
>> Just to recap the intended behavior: the timer should trigger the
>> corresponding oneshot service 5 min after the timer
Am 26.07.20 um 21:36 schrieb Francesco Poli:
> Control: reassign -1 systemd
>
>
> On Fri, 17 Jul 2020 18:11:08 +0200 Francesco Poli wrote:
>
>> On Fri, 17 Jul 2020 01:46:06 +0200 Michael Biebl wrote:
> [...]
>>> network-online.target is only relevant during boot, once the target has
>>> been
Control: reassign -1 systemd
On Fri, 17 Jul 2020 18:11:08 +0200 Francesco Poli wrote:
> On Fri, 17 Jul 2020 01:46:06 +0200 Michael Biebl wrote:
[...]
> > network-online.target is only relevant during boot, once the target has
> > been reached, it will stay up, it is not dynamic.
> > I.e. you
On Fri, 17 Jul 2020 01:46:06 +0200 Michael Biebl wrote:
> Control: reassign -1 apt-listbugs
>
> Am 16.07.20 um 23:11 schrieb Francesco Poli:
>
> > [Unit]
> > Description=Daily apt-listbugs preferences cleanup
> > After=network.target network-online.target
>
>
> > On the other hand, the
Control: reassign -1 apt-listbugs
Am 16.07.20 um 23:11 schrieb Francesco Poli:
> [Unit]
> Description=Daily apt-listbugs preferences cleanup
> After=network.target network-online.target
> On the other hand, the original bug reporter (Oswald) sees that the
> service is triggered
Control: retitle -1 systemd: timer triggers service immediately after wake-up
from sleep
I forgot to change the bug report title...
Doing so now.
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
.
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
>
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?
On Tue, 14 Jul 2020 10:36:23 +0200 Oswald Buddenhagen wrote:
> On Mon, Jul 13, 2020 at 11:25:21PM +0200, Francesco Poli wrote:
> >I haven't found a satisfying strategy to get what I wanted.
> >
> ok, fair enough. please make sure the maintainers know about this
> requirement if you haven't done
On Mon, Jul 13, 2020 at 11:25:21PM +0200, Francesco Poli wrote:
I haven't found a satisfying strategy to get what I wanted.
ok, fair enough. please make sure the maintainers know about this
requirement if you haven't done so yet.
Could it be that the timer was just about to be triggered,
On Tue, 7 Jul 2020 23:08:03 +0200 Oswald Buddenhagen wrote:
> On Tue, Jul 07, 2020 at 10:53:59PM +0200, Francesco Poli wrote:
> >On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote:
> >> there is a report every hour despite it claiming to be a daily job.
> >> that's weird at least.
> >
>
On Tue, Jul 07, 2020 at 10:53:59PM +0200, Francesco Poli wrote:
On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote:
there is a report every hour despite it claiming to be a daily job.
that's weird at least.
It works this way by design. [...]
The rationale is: the job must be
On Tue, 7 Jul 2020 20:17:15 +0200 Oswald Buddenhagen wrote:
> On Tue, Jul 07, 2020 at 07:46:50PM +0200, Francesco Poli wrote:
> > • when did it begin?
> >
> i don't remember - i tend to ignore non-critical errors at first.
Mmmh, that's unfortunate: I think that knowing this would have helped a
On Tue, Jul 07, 2020 at 07:46:50PM +0200, Francesco Poli wrote:
• when did it begin?
i don't remember - i tend to ignore non-critical errors at first.
the journal doesn't say when it began, either, as it says that the
sevice "succeeded" despite the error mail ...
but there are actually
Control: tags -1 + moreinfo
On Tue, 07 Jul 2020 11:36:43 +0200 Oswald Buddenhagen wrote:
> Package: apt-listbugs
> Version: 0.1.32
> Severity: normal
>
> for some days/weeks now, i get this mail every day:
>
> --
> From: apt-listbugs timer
> To: root
> Subject:
Package: apt-listbugs
Version: 0.1.32
Severity: normal
for some days/weeks now, i get this mail every day:
--
From: apt-listbugs timer
To: root
Subject: prefclean output on ugly
/usr/libexec/apt-listbugs/prefclean:
E: getaddrinfo: Temporary failure in name resolution
31 matches
Mail list logo
