Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.15
-
Fix Version/s: N/A
-
Component/s: Platform Debian
-
Labels:None
-
Environment:Ubuntu 14.04 Trusty Tahr
Description
When attempting to pre-seed an installation with an administrative password, the generated files don't appear to be respecting the value set in debconf, while the server itself receives and updates the password.
Given the scenario, I generate a uuid as the root_password value, and set it with the following:
debconf-set-selections mariadb-server/root_password password $UUID debconf-set-selections mariadb-server/root_password_again password $UUID
the generated cnf files for mysqladmin do not reflect this update, nor does the mariadb server successfully start from the /etc/init.d/mysql job:
- Starting MariaDB database server mysqld
...fail!
contents from /etc/mysql/debian.cnf
# Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost user = debian-sys-maint password = is5Y3MdDlUM3ZzNv socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = debian-sys-maint password = is5Y3MdDlUM3ZzNv socket = /var/run/mysqld/mysqld.sock basedir = /usr
the mariadb root-password value is: 16974151-9e1d-4ca1-a585-2e4171de0e4e
Service refuses to start with the following in syslog:
Dec 11 17:29:05 charles-local-machine-4 /etc/mysql/debian-start[3166]: ERROR 2006 (HY000) at line 1731: MySQL server has gone away Dec 11 17:29:05 charles-local-machine-4 /etc/mysql/debian-start[3166]: FATAL ERROR: Upgrade failed Dec 11 17:29:05 charles-local-machine-4 /etc/mysql/debian-start[3224]: Checking for insecure root accounts. Dec 11 17:29:37 charles-local-machine-4 /etc/init.d/mysql[3777]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in Dec 11 17:29:37 charles-local-machine-4 /etc/init.d/mysql[3777]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed Dec 11 17:29:37 charles-local-machine-4 /etc/init.d/mysql[3777]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")' Dec 11 17:29:37 charles-local-machine-4 /etc/init.d/mysql[3777]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! Dec 11 17:29:37 charles-local-machine-4 /etc/init.d/mysql[3777]: Dec 11 17:30:08 charles-local-machine-4 /etc/init.d/mysql[4342]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in Dec 11 17:30:08 charles-local-machine-4 /etc/init.d/mysql[4342]: #007/usr/bin/mysqladmin: connect to server at 'localhost' failed Dec 11 17:30:08 charles-local-machine-4 /etc/init.d/mysql[4342]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")' Dec 11 17:30:08 charles-local-machine-4 /etc/init.d/mysql[4342]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! Dec 11 17:30:08 charles-local-machine-4 /etc/init.d/mysql[4342]:
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
For additional reference - here is the code that i'm using attempting to set the password - relevant code starts on line 98
As originally referenced, i was targeting the mariadb-server package, and it was brought to my attention the debconf selection should have continued to be mysql-server, which was updated and doesn't appear to have had a difference in the outcome.
charles butler The debconf sets the password of the MariaDB/MySQL root user. The MariaDB/MySQL debian-maint-user password is random and not set via user nor debconf.
See https://bazaar.launchpad.net/~charmers/charms/trusty/mysql/trunk/view/head:/hooks/config-changed on how James Page wrote the MySQL charm. Most of this should apply for MariaDB too.
Your log says that the mysqld failed to start. Please review the daemon log files on why it did not start.
Looks like the issue was on my end and not the debian packaging. I had replaced some vital configuration incorrectly which yielded the failure.
This was especially due in part of the binlog-location being non-existant. Mariadb panicked when attempting to come online without much of a notice as to why it failed to start. Upon noticing that and correcting - mariadb came online as expected. Thanks for taking a look Otto.
Hi Otto Kekäläinen,
Could you please consult on this – whether it's a bug, and if so, what would be the proper fix, especially if it works differently with your packages.
Thanks.