Processed: Re: Bug#913303: systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it

2024-05-27 Thread Debian Bug Tracking System
Processing control commands: > close -1 Bug #913303 [systemd] systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it Marked Bug as done -- 913303: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913303 Debian Bug Tracking System Contact ow...@bugs.debian.org with

Bug#913303: systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it

2019-03-09 Thread Michael Biebl
On Sun, 11 Nov 2018 11:43:19 +0100 Michael Biebl wrote: > Am 11.11.18 um 11:41 schrieb Michael Biebl: > > Could you please file an issue at > > https://github.com/systemd/systemd/issues > > Ideally, before doing so, it would be good to verify that this behaviour > is still reproducible with the c

Bug#913303: systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it

2018-11-11 Thread Michael Biebl
Am 09.11.18 um 11:49 schrieb Lars Luthman: > When the computer is suspended, the randomized delay keeps on running instead > of pausing, and when it's woken up, the timer is 7 minutes nearer to expiring > rather than 0 minutes as expected. If the delay expires while the computer is > suspended, sy

Bug#913303: systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it

2018-11-11 Thread Michael Biebl
Am 11.11.18 um 11:41 schrieb Michael Biebl: > Could you please file an issue at > https://github.com/systemd/systemd/issues Ideally, before doing so, it would be good to verify that this behaviour is still reproducible with the current upstream version, i.e. v239, which is available in sid/buster

Bug#913303: systemd: RandomizedDelaySec should inherit the clock of the timer that triggered it

2018-11-09 Thread Lars Luthman
Package: systemd Version: 232-25+deb9u4 Severity: normal When using RandomizedDelaySec, the random delay that is added is treated as delay in calendar time (not paused during system suspension) even if the timer that triggered the random delay is one of the 'monotonic' timers that _should_ be paus