Discussion:
timezone aware timers
(too old to reply)
Iain Lane
2018-02-20 11:14:51 UTC
Permalink
Raw Message
Hi systemd friends,

Sorry if this has been discussed already.

I'm working on an alarm program. To allow the program to be shut down
between alarms, they are represented as systemd timers using OnCalendar
specifications. This mostly works but I think there is one wrinkle
remaining - they don't handle timezone transitions but always trigger in
the timezone that was in use when they were started.

In addition to alarms, you might also want this to schedule housekeeping
tasks or backups to happen in the night. I think the semantics would be
something like -

* When changing timezones, ensure timers will activate at their
configured time in the new local timezone.
* Ignore any activation times that are skipped over due to a timezone
change.

I'm not sure, though, what the best way to specify this in a timer unit
would be. Perhaps either a new timezone specification "local", or a
boolean flag UpdateWithTimezoneChange. "local" would act like you
specified the current timezone, but we would go away and recalculate
the time on a timezone change.

I also don't know how we'd get notified of the timezone changing.
inotify on /etc/timezone?

WDYT? (Should I report this as an issue instead?)

Cheers,

--
Iain Lane [ ***@orangesquash.org.uk ]
Debian Developer [ ***@debian.org ]
Ubuntu Developer [ ***@ubuntu.com ]
Lennart Poettering
2018-02-20 17:04:47 UTC
Permalink
Raw Message
On Di, 20.02.18 11:14, Iain Lane (***@orangesquash.org.uk) wrote:

> Hi systemd friends,
>
> Sorry if this has been discussed already.
>
> I'm working on an alarm program. To allow the program to be shut down
> between alarms, they are represented as systemd timers using OnCalendar
> specifications. This mostly works but I think there is one wrinkle
> remaining - they don't handle timezone transitions but always trigger in
> the timezone that was in use when they were started.
>
> In addition to alarms, you might also want this to schedule housekeeping
> tasks or backups to happen in the night. I think the semantics would be
> something like -
>
> * When changing timezones, ensure timers will activate at their
> configured time in the new local timezone.
> * Ignore any activation times that are skipped over due to a timezone
> change.
>
> I'm not sure, though, what the best way to specify this in a timer unit
> would be. Perhaps either a new timezone specification "local", or a
> boolean flag UpdateWithTimezoneChange. "local" would act like you
> specified the current timezone, but we would go away and recalculate
> the time on a timezone change.

If you don't specify a timezone in timer expression you actually
reference the local time. The only issue is that we don't recognize
timezone changes...

Could you file an RFE issue about this on github?

> I also don't know how we'd get notified of the timezone changing.
> inotify on /etc/timezone?

/etc/timezone is usually a symlink, and iirc we can't install inotify
on a symlink (only in the containing dir, but that means a lot more
wakeups).

The alternative is to watch timedated's bus signals, but quite frankly
I am not too keen on that, since PID 1 depending on service's APIs is
always messy, and means early-boot timezone changes couldn't be
covered (which are not unlikely, since timezone info can be
distributed via dhcp)

So, yeah, maybe a careful /etc inotify watch would be the best option
here after all. Happy to take a PR for that ;-)

(We can probably reuse similar code in journald, to fix #6589)

Lennart

--
Lennart Poettering, Red Hat
Dan Nicholson
2018-02-20 17:20:38 UTC
Permalink
Raw Message
On Tue, Feb 20, 2018 at 11:04 AM, Lennart Poettering
<***@poettering.net> wrote:
> On Di, 20.02.18 11:14, Iain Lane (***@orangesquash.org.uk) wrote:
>
>> I also don't know how we'd get notified of the timezone changing.
>> inotify on /etc/timezone?
>
> /etc/timezone is usually a symlink, and iirc we can't install inotify
> on a symlink (only in the containing dir, but that means a lot more
> wakeups).

Drive-by comment: the file you want to watch is /etc/localtime. That's
what glibc reads to get the default timezone in preference to the $TZ
environment variable -
http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.
/etc/timezone is just a Debian thing to keep the name of the timezone.
I'm not sure what uses that file.
Lennart Poettering
2018-02-20 17:37:59 UTC
Permalink
Raw Message
On Di, 20.02.18 11:20, Dan Nicholson (***@endlessm.com) wrote:

> On Tue, Feb 20, 2018 at 11:04 AM, Lennart Poettering
> <***@poettering.net> wrote:
> > On Di, 20.02.18 11:14, Iain Lane (***@orangesquash.org.uk) wrote:
> >
> >> I also don't know how we'd get notified of the timezone changing.
> >> inotify on /etc/timezone?
> >
> > /etc/timezone is usually a symlink, and iirc we can't install inotify
> > on a symlink (only in the containing dir, but that means a lot more
> > wakeups).
>
> Drive-by comment: the file you want to watch is /etc/localtime. That's
> what glibc reads to get the default timezone in preference to the $TZ
> environment variable -
> http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html.
> /etc/timezone is just a Debian thing to keep the name of the timezone.
> I'm not sure what uses that file.

True, we dropped /etc/timezone a long time ago. /etc/localtime is the
way to go, and the timezone is supposed to be read from the symlink
content.

Lennart

--
Lennart Poettering, Red Hat
Iain Lane
2018-02-20 17:29:06 UTC
Permalink
Raw Message
On Tue, Feb 20, 2018 at 06:04:47PM +0100, Lennart Poettering wrote:
> On Di, 20.02.18 11:14, Iain Lane (***@orangesquash.org.uk) wrote:
> > I'm not sure, though, what the best way to specify this in a timer unit
> > would be. Perhaps either a new timezone specification "local", or a
> > boolean flag UpdateWithTimezoneChange. "local" would act like you
> > specified the current timezone, but we would go away and recalculate
> > the time on a timezone change.
>
> If you don't specify a timezone in timer expression you actually
> reference the local time. The only issue is that we don't recognize
> timezone changes...

That's right. This is the intended behaviour though, so I'm proposing a
way to opt into something different. My feeling is that "local" is a
confusing name, but we could hash that out at a later stage.

> Could you file an RFE issue about this on github?

Yep. I filed #8233 now. Let's carry on there.

Cheers,

--
Iain Lane [ ***@orangesquash.org.uk ]
Debian Developer [ ***@debian.org ]
Ubuntu Developer [ ***@ubuntu.com ]
Lennart Poettering
2018-02-20 17:42:17 UTC
Permalink
Raw Message
On Di, 20.02.18 17:29, Iain Lane (***@orangesquash.org.uk) wrote:

> On Tue, Feb 20, 2018 at 06:04:47PM +0100, Lennart Poettering wrote:
> > On Di, 20.02.18 11:14, Iain Lane (***@orangesquash.org.uk) wrote:
> > > I'm not sure, though, what the best way to specify this in a timer unit
> > > would be. Perhaps either a new timezone specification "local", or a
> > > boolean flag UpdateWithTimezoneChange. "local" would act like you
> > > specified the current timezone, but we would go away and recalculate
> > > the time on a timezone change.
> >
> > If you don't specify a timezone in timer expression you actually
> > reference the local time. The only issue is that we don't recognize
> > timezone changes...
>
> That's right. This is the intended behaviour though, so I'm proposing a
> way to opt into something different. My feeling is that "local" is a
> confusing name, but we could hash that out at a later stage.

I think we should fix systemd so that specifying no timezone means
"follow the local timezone". I wouldn't even call that an API
breakage, but just a fix.

Lennart

--
Lennart Poettering, Red Hat
Loading...