[gentoo-amd64] Systemd timers screwed up by DST change?

[gentoo-amd64] Systemd timers screwed up by DST change?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]

Hi list

I've got a weird problem: after booting my computer (which was off during the
DST change last night) my bi-hourly backup timer didn't run as it would
normally do.  Looking at the list of timers, it is next scheduled to run at
midnight tonight:

    # systemctl list-timers 
    NEXT                         LEFT        LAST                         PASSED             UNIT                           ACTIVATES
    [...]
    Mo 2015-03-30 00:00:00 CEST  10h left    So 2015-03-29 00:00:01 CET   12h ago            backup-hourly.timer            backup@hourly.service
    [...]

The timer is defined thusly:

    # cat /etc/systemd/system/backup-hourly.timer
    [Unit]
    Description=Run hourly backups (timer)

    [Timer]
    OnCalendar=0/2:00
    Persistent=True
    Unit=backup@hourly.service

    [Install]
    WantedBy=timers.target

Has anybody else seen anything similar today?  I've never seen anything like
this happen before, so I wouldn't be surprised if it's related to the DST
change.  Also, in the event that it matters: I use chrony instead of timesyncd.

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-amd64] Systemd timers screwed up by DST change?

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Sun, Mar 29, 2015 at 5:27 AM, Marc Joliet <marcec@gmx.de> wrote:
>
> Hi list
>
> I've got a weird problem: after booting my computer (which was off during
the
> DST change last night) my bi-hourly backup timer didn't run as it would
> normally do.  Looking at the list of timers, it is next scheduled to run
at
> midnight tonight:
>
>     # systemctl list-timers
>     NEXT                         LEFT        LAST
PASSED             UNIT                           ACTIVATES
>     [...]
>     Mo 2015-03-30 00:00:00 CEST  10h left    So 2015-03-29 00:00:01 CET
12h ago            backup-hourly.timer            backup@hourly.service
>     [...]
>
> The timer is defined thusly:
>
>     # cat /etc/systemd/system/backup-hourly.timer
>     [Unit]
>     Description=Run hourly backups (timer)
>
>     [Timer]
>     OnCalendar=0/2:00
>     Persistent=True
>     Unit=backup@hourly.service
>
>     [Install]
>     WantedBy=timers.target
>
> Has anybody else seen anything similar today?  I've never seen anything
like
> this happen before, so I wouldn't be surprised if it's related to the DST
> change.  Also, in the event that it matters: I use chrony instead of
timesyncd.

Are you really sure "0/2:00" means "every 2 hours"? I don't see an explicit
mention in man 7 systemd.time that 0 means "*-*-* 00:00:00". It really
worked bi-hourly before?

Either way, it cretainly could be a bug.

Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 1982 bytes --]

Re: [gentoo-amd64] Systemd timers screwed up by DST change?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]

Am Sun, 29 Mar 2015 12:48:18 -0600
schrieb Canek Peláez Valdés <caneko@gmail.com>:

[...]
> Are you really sure "0/2:00" means "every 2 hours"? I don't see an explicit
> mention in man 7 systemd.time that 0 means "*-*-* 00:00:00". It really
> worked bi-hourly before?

Yes, it definitely worked before (I've been running this and other timers for
about a month). I don't remember how I inferred that rule, but I think it was
this bit from systemd.time(7):

    "Either time or date specification may be omitted, in which case the
    current day and 00:00:00 is implied, respectively. If the second component
    is not specified, ":00" is assumed."

But I don't see any definition for these components, so maybe I'm wrong and my
timer only works by accident.

> Either way, it cretainly could be a bug.

Perhaps, since it's back to the way it was before:

    # systemctl list-timers
    NEXT                         LEFT          LAST                         PASSED             UNIT                           ACTIVATES
    Mo 2015-03-30 02:00:00 CEST  1h 44min left Mo 2015-03-30 00:00:00 CEST  15min ago          backup-hourly.timer            backup@hourly.service
    [...]

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-amd64] Systemd timers screwed up by DST change?

[Canek Peláez Valdés]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

On Sun, Mar 29, 2015 at 4:32 PM, Marc Joliet <marcec@gmx.de> wrote:
>
> Am Sun, 29 Mar 2015 12:48:18 -0600
> schrieb Canek Peláez Valdés <caneko@gmail.com>:
>
> [...]
> > Are you really sure "0/2:00" means "every 2 hours"? I don't see an
explicit
> > mention in man 7 systemd.time that 0 means "*-*-* 00:00:00". It really
> > worked bi-hourly before?
>
> Yes, it definitely worked before (I've been running this and other timers
for
> about a month). I don't remember how I inferred that rule, but I think it
was
> this bit from systemd.time(7):
>
>     "Either time or date specification may be omitted, in which case the
>     current day and 00:00:00 is implied, respectively. If the second
component
>     is not specified, ":00" is assumed."
>
> But I don't see any definition for these components, so maybe I'm wrong
and my
> timer only works by accident.
>
> > Either way, it cretainly could be a bug.
>
> Perhaps, since it's back to the way it was before:
>
>     # systemctl list-timers
>     NEXT                         LEFT          LAST
  PASSED             UNIT                           ACTIVATES
>     Mo 2015-03-30 02:00:00 CEST  1h 44min left Mo 2015-03-30 00:00:00
CEST  15min ago          backup-hourly.timer
 backup@hourly.service
>     [...]

Perhaps the bug is only in how systemctl presents the information.

Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 1948 bytes --]

Re: [gentoo-amd64] Systemd timers screwed up by DST change?

[Marc Joliet]

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

Am Sun, 29 Mar 2015 16:49:21 -0600
schrieb Canek Peláez Valdés <caneko@gmail.com>:

> On Sun, Mar 29, 2015 at 4:32 PM, Marc Joliet <marcec@gmx.de> wrote:
> >
> > Am Sun, 29 Mar 2015 12:48:18 -0600
> > schrieb Canek Peláez Valdés <caneko@gmail.com>:
> >
> > [...]
> > > Are you really sure "0/2:00" means "every 2 hours"? I don't see an
> explicit
> > > mention in man 7 systemd.time that 0 means "*-*-* 00:00:00". It really
> > > worked bi-hourly before?
> >
> > Yes, it definitely worked before (I've been running this and other timers
> for
> > about a month). I don't remember how I inferred that rule, but I think it
> was
> > this bit from systemd.time(7):
> >
> >     "Either time or date specification may be omitted, in which case the
> >     current day and 00:00:00 is implied, respectively. If the second
> component
> >     is not specified, ":00" is assumed."
> >
> > But I don't see any definition for these components, so maybe I'm wrong
> and my
> > timer only works by accident.
> >
> > > Either way, it cretainly could be a bug.
> >
> > Perhaps, since it's back to the way it was before:
> >
> >     # systemctl list-timers
> >     NEXT                         LEFT          LAST
>   PASSED             UNIT                           ACTIVATES
> >     Mo 2015-03-30 02:00:00 CEST  1h 44min left Mo 2015-03-30 00:00:00
> CEST  15min ago          backup-hourly.timer
>  backup@hourly.service
> >     [...]
> 
> Perhaps the bug is only in how systemctl presents the information.

If I understand you correctly, then no: backup@hourly.service did not run
in spite of the contradictory next run time.  The only times it ran were when I
manually started it intermittently.

I suppose I'll have to file a bug report.  At the very least I'll find out if
this was a systemd bug or not.

Greetings
-- 
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]