Статья, которой по идее вообще не суждено было появиться на свет и которая ярко иллюстрирует разницу между теорией и практикой.

Да, я прекрасно понимаю что после статей про кросс‑компиляцию FreeBSD→CP/M или разработку на Java без всего мягко говоря странно писать на столь обывательскую тему, благо говностатей в интернете, рассказывающих как сбросить этот проклятый пароль навалом.

Но только все они.. ныне не работают.

Вот такие дела, обратная совместимость ныне не в чести даже у столь известных и популярных проектов как MySQL.

Проблема

Как нетрудно догадаться, автор занимается разработкой ПО, поэтому у него регулярно на рабочих машинах появляются самые разные базы данных.

Чаще всего это PostgreSQL, но пара проектов потребовала когда-то установки MySQL, что я и сделал, развернув стандартный MySQL Server из пакетов в одной из рабочих машин на Ubuntu Linux.

И про него успешно забыл.

Прошел год, затем другой, Ubuntu все это время обновлялась, как и MySQL сервер.

Наконец появилась производственная необходимость развернуть образ базы в MySQL, из-за чего я открыл любимый DBeaver, попытался подключиться и.. получил ошибку авторизации.

Открыл консоль и попытался подключиться стандартным клиентом:

Да, я самым банальным образом забыл пароль пользователя root, который в MySQL до сих пор отвечает за полный доступ и имеет все права.

Ресерч

Беглый поиск в интернете (это теперь практически тоже самое что и запрос к нейросетям) выдал кучу однотипных статей разных лет, не учитывающих современные реалии:

Думаю будет нетрудно догадаться, что проект MySQL развивается и за 12 лет успело многое поменяться, поэтому AI-выдача также показала логически верный, технически правильный но неработающий ответ:

Решение

Итак, речь в статье пойдет про 8.4 версию оригинального MySQL, выпускаемого ныне корпорацией Oracle, не про его форк MariaDB:

Действие происходит на вполне обыденной Ubuntu, а не какой-нибудь OpenBSD:

Так что свалить все описываемые проблемы на специфику окружения не получится.

С начала времен безопасность в MySQL была предметом шуток и анекдотов, поскольку всегда была отключаемой.

Так что вся эта проблема со сбросом пароля в MySQL — сама по себе тянет на хороший анекдот.

Собственно эта команда (скрипт — см. ниже) как раз и отвечала за запуск движка СУБД без авторизации и прав:

mysqld_safe --skip-grant-tables --skip-networking 

Но только в новых версиях MySQL есть нюанс:

mysqld_safe это на самом деле шелл-скрипт, который использует каталог /var/run/mysqld, которого внезапно при обычном использовании MySQL-сервера не создается.

Без этого каталога mysqld_safe не запустится, выдав что-то типа такого:

mysqld_safe --skip-grant-tables --skip-networking
2025-09-20T15:28:00.145945Z mysqld_safe Logging to '/var/log/mysql/error.log'.
2025-09-20T15:28:00.148210Z mysqld_safe Directory '/var/run/mysqld' for UNIX socket file don't exists.

Так что каталог придется создать:

mkdir -p /var/run/mysqld

Но и это тоже еще не все, при попытке запуска mysqld_safe банально упадет:

mysqld_safe --skip-grant-tables --skip-networking  
2025-09-20T15:30:10.637905Z mysqld_safe Logging to '/var/log/mysql/error.log'.
2025-09-20T15:30:10.658364Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2025-09-20T15:30:13.317240Z mysqld_safe mysqld from pid file /var/lib/mysql/ubunchu.pid ended

Как уже было отмечено выше, mysqld_safe это скрипт, который запускает настоящий бинарник (приложение) сервера MySQL и контролирует его состояние.

И запускает процесс mysqld он (какой сюрпиз) не от текущего пользователя а от выделенного пользователя mysql, у которого прав на этот каталог по-умолчанию нет.

Так что выдаем права:

сhown mysql /var/run/mysqld/

Теперь наконец mysqld_safe запустится:

mysqld_safe --skip-grant-tables --skip-networking 
2025-09-20T15:33:31.905740Z mysqld_safe Logging to '/var/log/mysql/error.log'.
2025-09-20T15:33:31.925688Z mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

И даже можно подключиться клиентом:

Но едем дальше.

По классике пароль в MySQL сбрасывается с помощью такого SQL-запроса:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'password';

Именно этот вариант вам подскажет любимая нейросеть:

Но только на практике оно больше не работает:

mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'password';
ERROR 1524 (HY000): Plugin 'auth_socket' is not loaded

А работает вот так:

use mysql;
update user set authentication_string='' where User='root';
update user set plugin="mysql_native_password" where User='root'; 
FLUSH PRIVILEGES;

Теперь наконец грохаем процессы mysql, поскольку по-другому остановить mysqld_safe не выйдет:

pkill -9 mysql

И включаем поддержку этих самых native_password (хотя-бы временно):

echo mysql_native_password=ON >> /etc/mysql/mysql.conf.d/mysqld.cnf

Теперь наконец можно запустить MySQL-сервер в штатном режиме:

systemctl start mysql

Процесс mysqld должен быть виден в списке запущенных, а статус сервиса должен выглядеть как-то так:

Теперь должно проходить подключение с помощью консольного клиента с пустым паролем:

Разумеется решение временное, поэтому дальше надо запустить скрипт mysql_secure_installation и с его помощью закончить настройку, в том числе задав новый пароль root и отключив поддержку native_password.

Вот такие дела.

Эпилог

Я бы не стал заморачиваться и тащить эту статью на Хабр, если бы не одно важное «но»:

то что вы прочитали выше — яркая иллюстрация разницы между теорией и практикой.

Самый популярный дистрибутив Linux, одна из самых популярных СУБД на планете, с долгой историей использования, еще и поддерживаемая мировой корпорацией и вот такой плачевный результат.

Если вы думали, будто ИИ способен решать проблемы в ИТ и достаточно лишь следовать его рекомендациям — статья выше это яркая иллюстрация обратного.

Добавлю, что все крупные поисковые системы уже реализовали блок выдачи ответов ИИ, но за все время использования я ни разу не встречал в выдаче ни одного работающего ответа.

Все что выдает ИИ во всех случаях является синтаксически верным, технически грамотным.. полностью неработающим бредом, к великому разочарованию.

Почему так происходит думаю лучше ответят специалисты по ИИ, но коль даже мировые корпорации до сих пор не могут заставить это работать — есть ли смысл полагаться на выдачу ИИ вам?

P.S.

Оригинал как обычно в нашем блоге, копия статьи на Дзене.

ИИ мы на самом деле любим и используем, но считаем что он нужен больше для генерации картинок с Натали Портман в декорациях питерской коммуналки, но не как инструмент для замены живым программистам.