Automatic update failing sometimes about tzdata

[lau]

@jamesotron @whitepaperclip

There was an error in the newest tz data (2019a) from IANA. See https://mm.icann.org/pipermail/tz/2019-March/027820.html
This means that there will be an error when trying to update, but except for seeing the error, everything should work fine using the previous version of the data.

Once 2019b comes out some day, it should work correctly for existing versions of this library.

I plan to get a new version of this library out that uses the version file instead of the NEWS file to get the version of the data. Previously the version file did not exist, but now that seems to be the best way to get the version.

[lau]

I recommend upgrading to version 0.5.11

{:tzdata, "~> 0.5.11"}

[muhmi]

Hi!

I am still getting this error:

2015-10-29 00:09:57.484 module=Tzdata.ReleaseUpdater line=30 [debug] Tzdata polling for update.
2015-10-29 00:09:57.901 module=Tzdata.DataLoader line=8 [debug] Tzdata downloading new data from https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz
2015-10-29 00:09:58.441 module=Tzdata.DataLoader line=19 [debug] Tzdata data downloaded. Release version 2015g.
2015-10-29 00:10:02.585 [error] GenServer Tzdata.EtsHolder terminating
** (MatchError) no match of right hand side value: {:error, :cannot_create_table}
    (tzdata) lib/tzdata/ets_holder.ex:51: Tzdata.EtsHolder.load_ets_table/1
    (tzdata) lib/tzdata/ets_holder.ex:44: Tzdata.EtsHolder.load_release/0
    (tzdata) lib/tzdata/ets_holder.ex:21: Tzdata.EtsHolder.handle_cast/2
    (stdlib) gen_server.erl:615: :gen_server.try_dispatch/4
    (stdlib) gen_server.erl:681: :gen_server.handle_msg/5
    (stdlib) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
Last message: {:"$gen_cast", :new_release_has_been_downloaded}
State: "2015f"

=CRASH REPORT==== 29-Oct-2015::00:10:02 ===
  crasher:
    initial call: Elixir.Tzdata.EtsHolder:init/1
    pid: <0.1088.0>
    registered_name: 'Elixir.Tzdata.EtsHolder'
    exception exit: {{badmatch,{error,cannot_create_table}},
                     [{'Elixir.Tzdata.EtsHolder',load_ets_table,1,
                          [{file,"lib/tzdata/ets_holder.ex"},{line,51}]},
                      {'Elixir.Tzdata.EtsHolder',load_release,0,
                          [{file,"lib/tzdata/ets_holder.ex"},{line,44}]},
                      {'Elixir.Tzdata.EtsHolder',handle_cast,2,
                          [{file,"lib/tzdata/ets_holder.ex"},{line,21}]},
                      {gen_server,try_dispatch,4,
                          [{file,"gen_server.erl"},{line,615}]},
                      {gen_server,handle_msg,5,
                          [{file,"gen_server.erl"},{line,681}]},
                      {proc_lib,init_p_do_apply,3,
                          [{file,"proc_lib.erl"},{line,240}]}]}
      in function  gen_server:terminate/7 (gen_server.erl, line 826)
    ancestors: [<0.1087.0>,<0.1086.0>]
    messages: []
    links: [<0.1087.0>]
    dictionary: []
    trap_exit: false
    status: running
    heap_size: 28690
    stack_size: 27
    reductions: 35598
  neighbours:

=SUPERVISOR REPORT==== 29-Oct-2015::00:10:02 ===
     Supervisor: {<0.1087.0>,'Elixir.Tzdata.EtsHolderSupervisor'}
     Context:    child_terminated
     Reason:     {{badmatch,{error,cannot_create_table}},
                  [{'Elixir.Tzdata.EtsHolder',load_ets_table,1,
                       [{file,"lib/tzdata/ets_holder.ex"},{line,51}]},
                   {'Elixir.Tzdata.EtsHolder',load_release,0,
                       [{file,"lib/tzdata/ets_holder.ex"},{line,44}]},
                   {'Elixir.Tzdata.EtsHolder',handle_cast,2,
                       [{file,"lib/tzdata/ets_holder.ex"},{line,21}]},
                   {gen_server,try_dispatch,4,
                       [{file,"gen_server.erl"},{line,615}]},
                   {gen_server,handle_msg,5,
                       [{file,"gen_server.erl"},{line,681}]},
                   {proc_lib,init_p_do_apply,3,
                       [{file,"proc_lib.erl"},{line,240}]}]}
     Offender:   [{pid,<0.1088.0>},
                  {id,'Elixir.Tzdata.EtsHolder'},
                  {mfargs,
                      {'Elixir.Tzdata.EtsHolder',start_link,
                          [[{name,'Elixir.Tzdata.EtsHolder'}]]}},
                  {restart_type,permanent},
                  {shutdown,5000},
                  {child_type,worker}]

[quatermain]

It's back, we got this error first time last week and we get it a lot of times from then. We use

{:tzdata, "~> 0.5.16"}

[jfayad]

Same here, using timex 3.0 which in turn uses tzdata 0.5.19

here is the error logged:

16:12:47.688 [error] GenServer Tzdata.EtsHolder terminating
elixir_1  | ** (MatchError) no match of right hand side value: {:error, :cannot_create_table}
elixir_1  |     (tzdata) lib/tzdata/ets_holder.ex:59: Tzdata.EtsHolder.load_ets_table/1
elixir_1  |     (tzdata) lib/tzdata/ets_holder.ex:52: Tzdata.EtsHolder.load_release/0
elixir_1  |     (tzdata) lib/tzdata/ets_holder.ex:23: Tzdata.EtsHolder.handle_cast/2
elixir_1  |     (stdlib) gen_server.erl:637: :gen_server.try_dispatch/4
elixir_1  |     (stdlib) gen_server.erl:711: :gen_server.handle_msg/6
elixir_1  |     (stdlib) proc_lib.erl:249: :proc_lib.init_p_do_apply/3
elixir_1  | Last message: {:"$gen_cast", :new_release_has_been_downloaded}

[lau]

I have seen that too. The problem is that for some reason iana.org returns an old file (version 2015f) sometimes. I am investigating the issue.

Tzdata will keep running, but you are right that it would be a good idea for Tzdata to handle this kind of situation specifically: when a downloaded version is older than the current loaded version.

[lau]

Apparently the problem is with one of the caching servers at IANA.

[tverlaan]

Thanks for looking into it. It will probably be fixed by IANA, but it would still be nice to ignore older versions then the one present.

[lau]

It seems that the issue has been fixed by IANA now.

[matteosister]

same here. Still getting the error.

[areski]

It appeared to me yesterday too, I would love to know what to do to avoid this.

[nkezhaya]

Same

[jimsynz]

This just happened to me also. IDK why. I'm assuming that it'll be fine.

[jimsynz]

Thanks @lau

[allenwyma]

thanks @lau looking forward to it :)

[paveltyk]

@lau thanks for the explanation

[vDupindev]

Same here!
Looking forward to it too !

[isaacsanders]

@lau If we deploy using a system like Kubernetes, we don't have a previous version of the database, potentially. Do you have any ideas for people in a situation like this?

[quatermain]

We have about 12 apps in kubernetes and it’s working. I think it loaded old version without restart.

…

-- Oliver Kriška [phone]

On 27 Mar 2019, 17:09 +0100, Isaac Sanders ***@***.***>, wrote: @lau If we deploy using a system like Kubernetes, we don't have a previous version of the database, potentially. Do you have any ideas for people in a situation like this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[isaacsanders]

I'm glad, but we regularly release new code and the dependency that Timex uses within this project is causing a fatal error for us.

[lau]

New releases are out that fixes this.

@isaacsanders The updater can crash if something goes wrong. However the updater is a separate process. So everything else should work fine in production even if the updater crashes.

Is the fatal error in a testing or Continuous Integration environment?

I haven't used Kubernetes, but if you can save files in a persistent volume the you can configure the "data dir" to be on a persistent volume. See https://github.com/lau/tzdata#data-directory-and-releases Alternatively you can disable automatic updates. However be aware that tz updates can happen frequently and with a short warning. So it requires more attention and "manual" work to check every day if there is a new release out and then updating your systems manually.

[pedroassumpcao]

Thanks @lau, really appreciate it, got the errors twice in the last 2 days.

[isaacsanders]

@lau The fatal error was in staging or production

[isaacsanders]

@lau @angelikatyborska Thanks for the quick turnaround on the release, though!