Mysql connection refused after upgrade to Ynh 4.1

Hi team,

Another instance and another trouble with upgrading. Sorry to bring it on you but I ran out of luck on that one :frowning_face:

My YunoHost server

Hardware: VPS in bulgaria
YunoHost version: 4.1.4.4
I have access to my server : Through SSH | through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

After upgrading the instance from 3.8 to 4.1 and doing the remaining migrations (till 0019), the zabbix app would not start after reboot. Error in the log is

1643:20210112:104637.645 [Z3001] connection to database 'zabbix' failed: [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111 "Connection refused")
1643:20210112:104637.645 database is down: reconnecting in 10 seconds

However mysql is running, and there is no error logged.

configuration: unknown
description: Stores app data (SQL database)
last_state_change: 2021-01-12 11:52:12
start_on_boot: enabled
status: running

and just after restarting the service :

$sudo service mysql status
Jan 15 12:56:44 b.tchack.xyz mysqld[7646]: 2021-01-15 12:56:44 0 [Note] /usr/sbin/mysqld: ready for connections.
Jan 15 12:56:44 b.tchack.xyz mysqld[7646]: Version: '10.3.27-MariaDB-0+deb10u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Debian 10
Jan 15 12:56:45 b.tchack.xyz systemd[1]: Started MariaDB 10.3.27 database server.
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7682]: Upgrading MySQL tables if necessary.
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7685]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7685]: Looking for 'mysql' as: /usr/bin/mysql
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7685]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7685]: This installation of MySQL is already upgraded to 10.3.27-MariaDB, use --force if you stil
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7693]: Checking for insecure root accounts.
Jan 15 12:56:45 b.tchack.xyz /etc/mysql/debian-start[7697]: Triggering myisam-recover for all MyISAM tables and aria-recover for all Aria tables

I then installed Adminer to look at the database, but it can’t log in either : Access denied for user 'root'@'localhost' when I use the /var/yunohost/mysql password. And I see the warning in the logs.

But-but-but : mysql -u root -p$(cat /etc/yunohost/mysql) mysql works well ! It logs and I can actually send commands, list tables, etc.

:face_with_monocle: Is there a step I missed in the upgrade ? What would you do from here on ? Thanks to all for your help and insights :smiley_cat:

So you stll get this error message

[Z3001] connection to database 'zabbix' failed: [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111 "Connection refused")

even after restarting mysql/mariadb …?

yes indeed !

To reinit root mysql password:

yunohost tools regen-conf mysql --force

okay, thanks for your quick replies. So this reset to the password of /etc/yunohost/mysql ? It seems to me that the password is okay since the login command runs OK in the shell.

Actually sudo yunohost tools regen-conf mysql -dn returns nothing, so I guessed that the good config was already in place. Should I still run --force to be sure ?

How did you test this point exactly ?

I thought I explained it in my first post, but maybe it was unclear :

So I’m able to log to mysql with the password managed by Ynh. Or is this not a good way to test this point ?
And again, when I use the very same set of user/password/db in the adminer app via web interface, login is denied.

Essaie avec:

source /usr/share/yunohost/helpers
ynh_mysql_execute_as_root --sql="SHOW TABLES;" --database="zabbix"

As root, it returns the list of tables, working alright. :sweat:

I ran the --force command just to be on the safe side, but it stills denies access from Adminer. God this is frustrating, I don’t where to look in the settings :anger: But thanks guys for your help and attention, hopefully I/we will overcome this.

Have you tired to log in on mysql with zabbix db_user and db_password (in cli) ?

When I execute mysql -u zabbix -p zabbix, it asks for the password (which I copied from the zabbix conf) and the login is allowed, I can then list tables.

I just did the last ynh upgrade (4.1.5) And the zabbix login to mysql is allowed via Adminer too !
But zabbix still wont start, and now it does not provide any log output xS Shit’s not getting clearer :imp:

followoing this thread, I see that my “GRANTS” use socket rather than password :face_with_monocle: :

MariaDB [mysql]> SHOW GRANTS;

| Grants for root@localhost                                                                                                                        |
+--------------------------------------------------------------------------------------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO `root`@`localhost` IDENTIFIED VIA unix_socket USING '*2C99EAB56A508DC87D6701B6359195FF0A43B832' WITH GRANT OPTION |
| GRANT PROXY ON ''@'%' TO 'root'@'localhost' WITH GRANT OPTION      

Is this a normal status ?

Yeah I don’t know either, I’m also puzzled by all these damn privileges configuration of mysql, it’s always hella mysterious and overly complicated.

I think the “unix_socket” authentication method is pretty cool though, it should allow you to just open a mysql shell with mysql -u root, no password needed considering that anyway you’re root on the machine…

(In fact I have a PR that I have yet to finish on this topic … No need for mysql root password by alexAubin · Pull Request #912 · YunoHost/yunohost · GitHub )

Hum, a new lead could be the presente of zabbix : Upgrade to Yunohost 4.0 failed · Issue #13 · YunoHost-Apps/zabbix_ynh · GitHub (but no details whatsoever on the actual reason of the bug…)

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.