On 04/10/17 22:11, Ondřej Surý wrote: > 1. what init system does your NAS have after upgrade?
paul@fuji ~ $ ll /sbin/init lrwxrwxrwx 1 root root 20 mrt 2 09:21 /sbin/init -> /lib/systemd/systemd > 2. did you reboot the system between removing mysql-server-5.5 and > mariadb-server-10.0 (purging /var/run on tmpfs)? Yes. Below some lines from /var/log/syslog <Un-installng mysql-server-5.5> Apr 7 11:03:43 fuji mysql[15397]: Stopping MySQL database server: mysqld. Apr 7 11:03:43 fuji systemd[1]: Stopped LSB: Start and stop the mysql database server daemon. <reboot (last one since by the way)> Apr 7 12:06:44 fuji kernel: [ 0.000000] Booting Linux on physical CPU 0x0 <first mentioning of MariaDB> Apr 7 12:45:43 fuji mysqld_safe[2798]: 2017-04-07 12:45:43 3062317056 [Note] /usr/sbin/mysqld (mysqld 10.1.22-MariaDB-) starting as process 2825 ... Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: Installation of system tables failed! Examine the logs in Apr 7 12:45:52 fuji mysqld_safe[2798]: /var/lib/mysql for more information. Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: The problem could be conflicting information in an external Apr 7 12:45:52 fuji mysqld_safe[2798]: my.cnf files. You can ignore these by doing: Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: shell> /usr/scripts/scripts/mysql_install_db --defaults-file=~/.my.cnf Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: You can also try to start the mysqld daemon with: Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: shell> /usr/sbin/mysqld --skip-grant --general-log & Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: and use the command line tool /usr/bin/mysql Apr 7 12:45:52 fuji mysqld_safe[2798]: to connect to the mysql database and look at the grant tables: Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: shell> /usr/bin/mysql -u root mysql Apr 7 12:45:52 fuji mysqld_safe[2798]: mysql> show tables; Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: Try 'mysqld --help' if you have problems with paths. Using Apr 7 12:45:52 fuji mysqld_safe[2798]: --general-log gives you a log in /var/lib/mysql that may be helpful. Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: The latest information about mysql_install_db is available at Apr 7 12:45:52 fuji mysqld_safe[2798]: https://mariadb.com/kb/en/installing-system-tables-mysql_install_db Apr 7 12:45:52 fuji mysqld_safe[2798]: MariaDB is hosted on launchpad; You can find the latest source and Apr 7 12:45:52 fuji mysqld_safe[2798]: email lists at http://launchpad.net/maria Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2798]: Please check all of the above before submitting a bug report Apr 7 12:45:52 fuji mysqld_safe[2798]: at http://mariadb.org/jira Apr 7 12:45:52 fuji mysqld_safe[2798]: Apr 7 12:45:52 fuji mysqld_safe[2858]: 2017-04-07 12:45:52 3062255616 [Note] /usr/sbin/mysqld (mysqld 10.1.22-MariaDB-) starting as process 2857 ... which coincides with the abort in /var/log/mysqld/error.log: 2017-04-07 12:45:49 3062317056 [ERROR] Aborting On 04/10/17 22:47, Ondřej Surý wrote: > Are you sure that you haven't done any manual changes to > /etc/init.d/mysql that would cause dpkg to not replace it with new > script? Yes. paul@fuji ~ $ ll /etc/init.d/mysql -rwxr-xr-x 1 root root 5930 mrt 28 22:59 /etc/init.d/mysql Which matches: mariadb-10.1 (10.1.22-3) unstable; urgency=medium -- Ondřej Surý <ond...@debian.org> Tue, 28 Mar 2017 22:59:06 +0200 > Is there something like /etc/init.d/mysql.dpkg-* present on your > NAS system (although I can start mariadb even with the old MySQL 5.5 > init.d script). No, paul@fuji ~ $ ll /etc/init.d/mysql* -rwxr-xr-x 1 root root 5930 mrt 28 22:59 /etc/init.d/mysql > Would you be willing to test it again on your system: > > a) stop mariadb server > b) rm -rf /var/run/mysqld > c) start mariadb server paul@fuji ~ $ sudo service mysql stop paul@fuji ~ $ sudo rmdir /var/run/mysqld/ paul@fuji ~ $ sudo service mysql start paul@fuji ~ $ ll /var/run/mysqld/ total 4 drwxr-xr-x 2 mysql root 80 apr 11 04:08 . drwxr-xr-x 26 root root 820 apr 11 04:08 .. -rw-rw---- 1 mysql mysql 6 apr 11 04:08 mysqld.pid srwxrwxrwx 1 mysql mysql 0 apr 11 04:08 mysqld.sock So, now it can properly succeed. > Does it fails to create /var/run/mysqld? If not, then (on sysvinit > system) output of: > > sh -x /etc/init.d/mysql start > > or on systemd init system output of > > journalctl --unit=mariadb > > would be appreciated. paul@fuji ~ $ sudo journalctl --unit=mariadb -- Logs begin at Mon 2017-04-10 23:56:51 CEST, end at Tue 2017-04-11 04:09:35 CEST. -- apr 11 04:07:18 fuji systemd[1]: Stopping MariaDB database server... apr 11 04:07:20 fuji systemd[1]: Stopped MariaDB database server. apr 11 04:08:08 fuji systemd[1]: Starting MariaDB database server... apr 11 04:08:10 fuji mysqld[21405]: 2017-04-11 4:08:10 3061743616 [Note] /usr/sbin/mysqld (mysqld 10.1.22-MariaDB-) starting as proces apr 11 04:08:12 fuji systemd[1]: Started MariaDB database server. > (Or can I catch you on IRC/Jabber/<other means of online > communications>?) I am elbrus on IRC and the last couple of days watching #debian-mysql. > Minor nits: > 1. systemd unit should use tmpfiles instead of running install -d > 2. there's a race condition where /var/run/mysqld is a dangling symlink, > but that's should not happen I am pretty sure that /var/run/mysqld didn't exist, not even as a dangling symlink. Paul
signature.asc
Description: OpenPGP digital signature
