Hello,
I first came across this problem on a computer I maintain for an elderly
relative who uses it only occasionally, typically two or three times a
week for about an hour each time. As that includes online banking, the
system was configured to use the "unattended-upgrades" package to keep up
wi
> This appears to be inconsistent imho.
>
> Somehow I think systemd could be more clever here and scale down
> RandomizedDelaySec= on boot depending on how far in the past the
> timestamp of the stampfile is.
> Say the last activation of the service was 12 hours ago, then scale
> down RandomizedDel
codesearch.debian.net shows the following timers with a
RandomizedDelaySec of 12h, which will likely run into the same problem.
fwupd_1.5.7-5/data/motd/fwupd-refresh.timer
[Timer]
OnCalendar=*-*-* 6,18:00
RandomizedDelaySec=12h
Persistent=true
apt_2.3.11/debian/apt-daily.timer
[Timer]
OnCale
On 28.10.21 09:05, Hendrik Buchner wrote:
Hello Michael and Julian,
that explains why the behaviour of "RandomizedDelaySec" together with
"Persistent" is different between buster and bullseye. If that's the
intended behaviour, my systems seems to work like they should and it's
no bug.
It's de
Hello Michael and Julian,
that explains why the behaviour of "RandomizedDelaySec" together with
"Persistent" is different between buster and bullseye. If that's the
intended behaviour, my systems seems to work like they should and it's
no bug.
So for me I will change the delay from 12h to maybe 5m
On Wed, Oct 27, 2021 at 09:50:39PM +0200, Michael Biebl wrote:
> On 27.10.21 21:42, Michael Biebl wrote:
> > Possibly related
> > https://github.com/systemd/systemd/pull/11608
>
> The commit message explains it rather well:
>
> https://github.com/systemd/systemd/pull/11608/commits/a87c1d3a979f8c2
On 27.10.21 21:42, Michael Biebl wrote:
Possibly related
https://github.com/systemd/systemd/pull/11608
The commit message explains it rather well:
https://github.com/systemd/systemd/pull/11608/commits/a87c1d3a979f8c2641471bed93577558a1027a24
core: delay persistent timers by "RandomizedDelayS
On 27.10.21 21:19, Michael Biebl wrote:
On 27.10.21 21:05, Michael Biebl wrote:
On 27.10.21 20:47, Michael Biebl wrote:
Important is this sentence:
"Such triggering is nonetheless subject to the delay imposed by
RandomizedDelaySec="
Keep in mind that RandomizedDelaySec= is not stored on di
Regarding the title of this bug report:
Afaics the Persistent= attribute is not ignored but the interpretation
of RandomizedDelaySec= has changed
OpenPGP_signature
Description: OpenPGP digital signature
On 27.10.21 21:05, Michael Biebl wrote:
On 27.10.21 20:47, Michael Biebl wrote:
Important is this sentence:
"Such triggering is nonetheless subject to the delay imposed by
RandomizedDelaySec="
Keep in mind that RandomizedDelaySec= is not stored on disk, only the
timestamp of the last execu
On 27.10.21 20:47, Michael Biebl wrote:
Important is this sentence:
"Such triggering is nonetheless subject to the delay imposed by
RandomizedDelaySec="
Keep in mind that RandomizedDelaySec= is not stored on disk, only the
timestamp of the last execution.
So, let's assume the service was l
Hello once again
On 27.10.21 20:17, Michael Biebl wrote:
On 27.10.21 16:05, Hendrik Buchner wrote:
Hello Michael,
my system isn't running on battery because it's a Desktop-PC and not a
laptop. I've observed this behaviour now on 3 of my computers (2
Desktop-PCs and 1 laptop).
Just to recap
>Is this issue only reproducible with apt-daily.timer and
>apt-daily-upgrade.timer works correctly?
I think so, but I will observe it for the next days.
>Does this issue happen reproducibly? Say "systemctl status
>apt-daily.timer" shows that the timer is about to elapse in 5 hours. If
>you shut d
On 27.10.21 16:05, Hendrik Buchner wrote:
Hello Michael,
my system isn't running on battery because it's a Desktop-PC and not a
laptop. I've observed this behaviour now on 3 of my computers (2
Desktop-PCs and 1 laptop).
Just to recap here:
- Is this issue only reproducible with apt-daily.time
On 27.10.21 16:16, Hendrik Buchner wrote:
I've attached the output of "journalctl -u apt-daily.service" and as
you can see, it has not been running as often as
"apt-daily-upgrade.service"
Can you mark in the log, when you upgraded your system and at what times
you shutdown/started the system a
I've attached the output of "journalctl -u apt-daily.service" and as
you can see, it has not been running as often as
"apt-daily-upgrade.service"
-- Journal begins at Sun 2021-08-15 08:33:03 CEST, ends at Wed 2021-10-27
16:11:14 CEST. --
Aug 15 08:57:42 HendrikDesktop systemd[1]: Starting Daily ap
Hello Michael,
my system isn't running on battery because it's a Desktop-PC and not a
laptop. I've observed this behaviour now on 3 of my computers (2
Desktop-PCs and 1 laptop).
Attached you can find the output of your "journalctl", but on this
system I haven't already changed the timer. If you n
Control: tags -1 + unreproducible moreinfo
Hello,
unfortunately, I can not confirm the issue (thus marking the bug report
accordingly).
Persistent timers are correctly "remembered" when shutdown/rebooted.
Have you seen that apt-daily-upgrade.service has
ConditionACPower=true
Maybe your sys
18 matches
Mail list logo
