Systemd timers screwed up by DST change?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Systemd timers screwed up by DST change?

Marc Joliet
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            [hidden email]
    [...]

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=[hidden email]

    [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

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Systemd timers screwed up by DST change?

Canek Peláez Valdés
On Sun, Mar 29, 2015 at 5:27 AM, Marc Joliet <[hidden email]> 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            [hidden email]
>     [...]
>
> 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=[hidden email]
>
>     [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
Reply | Threaded
Open this post in threaded view
|

Re: Systemd timers screwed up by DST change?

Marc Joliet
Am Sun, 29 Mar 2015 12:48:18 -0600
schrieb Canek Peláez Valdés <[hidden email]>:

[...]
> 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            [hidden email]
    [...]

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

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Systemd timers screwed up by DST change?

Canek Peláez Valdés
On Sun, Mar 29, 2015 at 4:32 PM, Marc Joliet <[hidden email]> wrote:

>
> Am Sun, 29 Mar 2015 12:48:18 -0600
> schrieb Canek Peláez Valdés <[hidden email]>:
>
> [...]
> > 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            [hidden email]
>     [...]

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
Reply | Threaded
Open this post in threaded view
|

Re: Systemd timers screwed up by DST change?

Marc Joliet
Am Sun, 29 Mar 2015 16:49:21 -0600
schrieb Canek Peláez Valdés <[hidden email]>:

> On Sun, Mar 29, 2015 at 4:32 PM, Marc Joliet <[hidden email]> wrote:
> >
> > Am Sun, 29 Mar 2015 12:48:18 -0600
> > schrieb Canek Peláez Valdés <[hidden email]>:
> >
> > [...]
> > > 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
>  [hidden email]
> >     [...]
>
> Perhaps the bug is only in how systemctl presents the information.
If I understand you correctly, then no: [hidden email] 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

attachment0 (836 bytes) Download Attachment