Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. Gentoo>
  3. AMD64
Systemd timers screwed up by DST change?
marcec at gmx
Mar 29, 2015, 4:27 AM
Post #1 of 5 (2272 views)
Permalink
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
Re: Systemd timers screwed up by DST change? [ In reply to ]
caneko at gmail
Mar 29, 2015, 11:48 AM
Post #2 of 5 (2230 views)
Permalink
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
Re: Systemd timers screwed up by DST change? [ In reply to ]
marcec at gmx
Mar 29, 2015, 3:32 PM
Post #3 of 5 (2229 views)
Permalink
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
Re: Systemd timers screwed up by DST change? [ In reply to ]
caneko at gmail
Mar 29, 2015, 3:49 PM
Post #4 of 5 (2228 views)
Permalink
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
Re: Systemd timers screwed up by DST change? [ In reply to ]
marcec at gmx
Mar 29, 2015, 4:04 PM
Post #5 of 5 (2233 views)
Permalink
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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal