[MDEV-13397] MariaDB upgrade fail when using default_time_zone Created: 2017-07-28  Updated: 2018-07-19  Resolved: 2018-07-19

Status: Closed
Project: MariaDB Server
Component/s: Server, Time zones
Affects Version/s: 10.0, 10.1
Fix Version/s: 10.0.36, 10.1.35

Type: Bug Priority: Major
Reporter: Nicolas Payart Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux Debian


 Description   

I am using official MariaDB APT repository on Debian 8 to install mariadb-server-10.1 package.

I populate timezone tables using:

/usr/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql mysql

Then setting default_time_zone variable in my.cnf:

[mysqld]
 
default_time_zone=Europe/Paris

After restarting mysql service all works fine:

:~# /etc/init.d/mysql restart
 
[ ok ] Restarting mysql (via systemctl): mysql.service.
 
:~# mysql -e "show variables like 'time_zone'"
 
+---------------+--------------+
 
| Variable_name | Value        |
 
+---------------+--------------+
 
| time_zone     | Europe/Paris |
 
+---------------+--------------+

The problem occurs when upgrading mariadb-server packages. For example, my last apt-get upgrade upgraded MariaDB from v10.1.22 to v10.1.25:

:~# apt-get upgrade
 
...
 
Errors were encountered while processing:
 
 mariadb-server-10.1
 
 mariadb-server
 
E: Sub-process /usr/bin/dpkg returned an error code (1)


:~# apt-get install -f
 
Reading package lists... Done
 
Building dependency tree       
Reading state information... Done
 
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 
2 not fully installed or removed.
 
After this operation, 0 B of additional disk space will be used.
 
Setting up mariadb-server-10.1 (10.1.25+maria-1~jessie) ...
 
dpkg: error processing package mariadb-server-10.1 (--configure):
 
 subprocess installed post-installation script returned error exit status 1
 
dpkg: dependency problems prevent configuration of mariadb-server:
 
 mariadb-server depends on mariadb-server-10.1 (= 10.1.25+maria-1~jessie); however:
 
  Package mariadb-server-10.1 is not configured yet.
 
 
 
dpkg: error processing package mariadb-server (--configure):
 
 dependency problems - leaving unconfigured
 
Errors were encountered while processing:
 
 mariadb-server-10.1
 
 mariadb-server
 
E: Sub-process /usr/bin/dpkg returned an error code (1)

MariaDB error log (/var/log/mysql.err) says:

2017-07-28 10:09:20 140185074391296 [ERROR] Fatal error: Illegal or unknown default time zone 'Europe/Paris'

If I comment the default_time_zone parameter in my.cnf, I can complete the upgrade process:

[mysqld]
 
#default_time_zone=Europe/Paris

Then, reintroducing default_time_zone parameter in my.cnf, I am able to restart mysql service without any problem.

It seems that something is broken in apt upgrade process when default_time_zone is set, whereas time zone tables are filled or not...

Other users have encountered the same problem as you can see on StackOverflow: https://stackoverflow.com/questions/29565278/apt-get-upgrade-always-fails-on-mariadb-server-due-to-timezone

 Comments   
Comment by Elena Stepanova [ 2017-08-01 ]

I'm not getting the problem:

Server version: 10.1.22-MariaDB-1~jessie mariadb.org binary distribution
 
 
 
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
 
 
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
 
 
MariaDB [(none)]> select @@time_zone;
 
+--------------+
 
| @@time_zone  |
 
+--------------+
 
| Europe/Paris |
 
+--------------+
 
1 row in set (0.00 sec)
 
 
 
MariaDB [(none)]> exit


$ dpkg -l | grep -iE 'maria|mysql'
 
ii  libdbd-mysql-perl              4.028-2+deb8u2                     amd64        Perl5 database interface to the MySQL database
 
ii  libmariadbclient18             10.1.22+maria-1~jessie             amd64        MariaDB database client library
 
ii  libmysqlclient18               10.1.22+maria-1~jessie             amd64        Virtual package to satisfy external depends
 
ii  mariadb-client-10.1            10.1.22+maria-1~jessie             amd64        MariaDB database client binaries
 
ii  mariadb-client-core-10.1       10.1.22+maria-1~jessie             amd64        MariaDB database core client binaries
 
ii  mariadb-common                 10.1.22+maria-1~jessie             all          MariaDB database common files (e.g. /etc/mysql/conf.d/mariadb.cnf)
 
ii  mariadb-server                 10.1.22+maria-1~jessie             all          MariaDB database server (metapackage depending on the latest version)
 
ii  mariadb-server-10.1            10.1.22+maria-1~jessie             amd64        MariaDB database server binaries
 
ii  mariadb-server-core-10.1       10.1.22+maria-1~jessie             amd64        MariaDB database core server files
 
ii  mysql-common                   10.1.22+maria-1~jessie             all          MariaDB database common files (e.g. /etc/mysql/my.cnf)


$ sudo apt-get upgrade
 
Reading package lists... Done
 
Building dependency tree       
Reading state information... Done
 
Calculating upgrade... Done
 
The following packages will be upgraded:
 
  libmariadbclient18 libmysqlclient18 mariadb-client-10.1 mariadb-client-core-10.1 mariadb-common mariadb-server mariadb-server-10.1
 
  mariadb-server-core-10.1 mysql-common
 
9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
 
Need to get 0 B/13.1 MB of archives.
 
After this operation, 50.2 kB of additional disk space will be used.
 
Do you want to continue? [Y/n] y
 
Reading changelogs... Done
 
Preconfiguring packages ...
 
(Reading database ... 33607 files and directories currently installed.)
 
Preparing to unpack .../mariadb-server_10.1.25+maria-1~jessie_all.deb ...
 
Unpacking mariadb-server (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../libmariadbclient18_10.1.25+maria-1~jessie_amd64.deb ...
 
Unpacking libmariadbclient18 (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../libmysqlclient18_10.1.25+maria-1~jessie_amd64.deb ...
 
Unpacking libmysqlclient18 (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../mysql-common_10.1.25+maria-1~jessie_all.deb ...
 
Unpacking mysql-common (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../mariadb-common_10.1.25+maria-1~jessie_all.deb ...
 
Unpacking mariadb-common (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../mariadb-client-core-10.1_10.1.25+maria-1~jessie_amd64.deb ...
 
Unpacking mariadb-client-core-10.1 (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../mariadb-client-10.1_10.1.25+maria-1~jessie_amd64.deb ...
 
Unpacking mariadb-client-10.1 (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Preparing to unpack .../mariadb-server-core-10.1_10.1.25+maria-1~jessie_amd64.deb ...
 
Unpacking mariadb-server-core-10.1 (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Processing triggers for man-db (2.7.0.2-5) ...
 
Setting up mysql-common (10.1.25+maria-1~jessie) ...
 
Setting up mariadb-common (10.1.25+maria-1~jessie) ...
 
(Reading database ... 33607 files and directories currently installed.)
 
Preparing to unpack .../mariadb-server-10.1_10.1.25+maria-1~jessie_amd64.deb ...
 
Unpacking mariadb-server-10.1 (10.1.25+maria-1~jessie) over (10.1.22+maria-1~jessie) ...
 
Processing triggers for systemd (215-17+deb8u7) ...
 
Processing triggers for man-db (2.7.0.2-5) ...
 
Setting up libmysqlclient18 (10.1.25+maria-1~jessie) ...
 
Setting up libmariadbclient18 (10.1.25+maria-1~jessie) ...
 
Setting up mariadb-client-core-10.1 (10.1.25+maria-1~jessie) ...
 
Setting up mariadb-client-10.1 (10.1.25+maria-1~jessie) ...
 
Setting up mariadb-server-core-10.1 (10.1.25+maria-1~jessie) ...
 
Setting up mariadb-server-10.1 (10.1.25+maria-1~jessie) ...
 
Setting up mariadb-server (10.1.25+maria-1~jessie) ...
 
Processing triggers for libc-bin (2.19-18+deb8u10) ...
 
$


$ dpkg -l | grep -iE 'maria|mysql'
 
ii  libdbd-mysql-perl              4.028-2+deb8u2                     amd64        Perl5 database interface to the MySQL database
 
ii  libmariadbclient18             10.1.25+maria-1~jessie             amd64        MariaDB database client library
 
ii  libmysqlclient18               10.1.25+maria-1~jessie             amd64        Virtual package to satisfy external depends
 
ii  mariadb-client-10.1            10.1.25+maria-1~jessie             amd64        MariaDB database client binaries
 
ii  mariadb-client-core-10.1       10.1.25+maria-1~jessie             amd64        MariaDB database core client binaries
 
ii  mariadb-common                 10.1.25+maria-1~jessie             all          MariaDB database common files (e.g. /etc/mysql/conf.d/mariadb.cnf)
 
ii  mariadb-server                 10.1.25+maria-1~jessie             all          MariaDB database server (metapackage depending on the latest version)
 
ii  mariadb-server-10.1            10.1.25+maria-1~jessie             amd64        MariaDB database server binaries
 
ii  mariadb-server-core-10.1       10.1.25+maria-1~jessie             amd64        MariaDB database core server files
 
ii  mysql-common                   10.1.25+maria-1~jessie             all          MariaDB database common files (e.g. /etc/mysql/my.cnf)


$ mysql -uroot -p -e "select @@time_zone, @@version"
 
Enter password: 
+--------------+--------------------------+
 
| @@time_zone  | @@version                |
 
+--------------+--------------------------+
 
| Europe/Paris | 10.1.25-MariaDB-1~jessie |
 
+--------------+--------------------------+

Is the problem reproducible for you? Can you paste the part of the upgrade stdout relevant to MariaDB upgrade?
Do you have any other non-default options in the config files, other than the time zone?
Did you change configuration of the systemd service in any way?

Comment by Daniel Krämer [ 2017-08-18 ]

Hi there
today was the release of 10.0.32-0 in Debian Jessie.

I ran into this Problem too!
To be clear, it just happens while post-installation script from package is running. If i comment the default-time-zone out it works, then i comment it in again, restart and everything is fine again.

Here is the output which surprised me, cause the database was running fine before:

170818 11:22:32 [Note] InnoDB: Using mutexes to ref count buffer pool pages
170818 11:22:32 [Note] InnoDB: The InnoDB memory heap is disabled
170818 11:22:32 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
170818 11:22:32 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
170818 11:22:32 [Note] InnoDB: Compressed tables use zlib 1.2.8
170818 11:22:32 [Note] InnoDB: Using Linux native AIO
170818 11:22:32 [Note] InnoDB: Using CPU crc32 instructions
170818 11:22:32 [Note] InnoDB: Initializing buffer pool, size = 998.0M
170818 11:22:32 [Note] InnoDB: Completed initialization of buffer pool
170818 11:22:32 [Note] InnoDB: Highest supported file format is Barracuda.
170818 11:22:32 [Note] InnoDB: 128 rollback segment(s) are active.
170818 11:22:32 [Note] InnoDB: Waiting for purge to start
170818 11:22:32 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 3992453178
170818 11:22:32 [Note] Plugin 'FEEDBACK' is disabled.
170818 11:22:32 [ERROR] Fatal error: Illegal or unknown default time zone 'Europe/Berlin'

Comment by Elena Stepanova [ 2017-09-15 ]

The error about timezones is not mysterious, it happens because postinst configure runs mysql_install_db (even though the database is already there, so it's mainly a redundant call), which in turn runs mysqld boostrap, which does not recognize timezones.

On some reason, it doesn't make upgrade to 10.1 (for which it was reported initially) fail for me. The error is still there, but upgrade proceeds and finishes successfully

However, for 10.0 it does indeed fail. It's unclear how it worked before if it did, it looks like bootstrap would always fail this way. Maybe something was different in Debian scripts or Debian upgrade process.

Comment by Elena Stepanova [ 2017-09-15 ]

serg, what do you think about it? Would it be easy to make boostrap be aware of previously loaded timezones? Or alternatively, do we need to run bootstrap every time upon upgrade?

Generated at Thu Feb 08 08:05:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.