Bug 238958 – [GTK][WPE] Clear ICU cache only on timezone changes

• Component: Platform
• Status: NEW

[Adrian Perez]

On Linux systems which run systemd-timedated, we can probable use
GDBus to watch the org.freedesktop.timedate1.Timezone property of
the /org/freedesktop/timedate1 system bus object.

The problem with the above approach is that many systems do not use
it (specially embedded ones running WPE, or BSDs running the GTK
port), so instead we may need to pick some info of /etc/localtime
(mtime, ctime, inode/device number?, …) and then only invalidate
the caches when those change.

Extra complication: the /etc/localtime file can be a symlink (and
it often is!) so it may be needed to track the properties of the
target file as well \:-\

Side question: does systemd-timedated take notice itself of changed
done manually to the /etc/localtime file *without* using timedatectl?

[Yusuke Suzuki]

(In reply to Adrian Perez from comment #0)
> On Linux systems which run systemd-timedated, we can probable use
> GDBus to watch the org.freedesktop.timedate1.Timezone property of
> the /org/freedesktop/timedate1 system bus object.
> 
> The problem with the above approach is that many systems do not use
> it (specially embedded ones running WPE, or BSDs running the GTK
> port), so instead we may need to pick some info of /etc/localtime
> (mtime, ctime, inode/device number?, …) and then only invalidate
> the caches when those change.
> 
> Extra complication: the /etc/localtime file can be a symlink (and
> it often is!) so it may be needed to track the properties of the
> target file as well \:-\
> 
> Side question: does systemd-timedated take notice itself of changed
> done manually to the /etc/localtime file *without* using timedatectl?

One way I can come up with is observing file change of /etc/localtime via inotify.

[Michael Catanzaro]

(In reply to Adrian Perez from comment #0)
> Side question: does systemd-timedated take notice itself of changed
> done manually to the /etc/localtime file *without* using timedatectl?

Poking around in systemd's timedated.c and time-util.c, I don't think it does, and I certainly don't think WebKit should be expected to be more careful than systemd.

But even if it did, remember that the timedated D-Bus API might be implemented by something other than systemd. E.g. a few years ago, systemd decided to drop support for all NTP daemons except timesyncd, but Fedora wanted to keep using chrony, so the chrony maintainer wrote timedatex and we used that for several years.

Regardless, inotify is a precious limited resource, and really should not be used from the web process at all if possible, certainly not for an edge case like this. It's not a theoretical problem: Epiphany currently crashes after opening 70-80 tabs because we hit some system limit on inotify handles, and I'm not sure what we can do to fix it.

[Yusuke Suzuki]

(In reply to Michael Catanzaro from comment #2)
> (In reply to Adrian Perez from comment #0)
> > Side question: does systemd-timedated take notice itself of changed
> > done manually to the /etc/localtime file *without* using timedatectl?
> 
> Poking around in systemd's timedated.c and time-util.c, I don't think it
> does, and I certainly don't think WebKit should be expected to be more
> careful than systemd.
> 
> But even if it did, remember that the timedated D-Bus API might be
> implemented by something other than systemd. E.g. a few years ago, systemd
> decided to drop support for all NTP daemons except timesyncd, but Fedora
> wanted to keep using chrony, so the chrony maintainer wrote timedatex and we
> used that for several years.
> 
> Regardless, inotify is a precious limited resource, and really should not be
> used from the web process at all if possible, certainly not for an edge case
> like this. It's not a theoretical problem: Epiphany currently crashes after
> opening 70-80 tabs because we hit some system limit on inotify handles, and
> I'm not sure what we can do to fix it.

If we have no way except for inotify, then, we can do that in Browser process side, and broadcast timezone change message to web content processes.
But if D-bus supports such a notification, probably it is enough.

[Michael Catanzaro]

Um, yes, good point. Except the web process won't have access to the system bus, so that too would have to be done in the browser process.