Столкнулся вчера на одном из серверов с ситуацией, которая взорвала мне мозг.

Столкнулся вчера на одном из серверов с ситуацией, которая взорвала мне мозг. Пол дня с ней провозился, пока не разобрался. Да и то считай, что случайно. Технического решения я так и не нашёл. Возможно кто-то подскажет его в комментариях.

Настраивал на почтовом сервере плагин для RoundCube, который позволяет пользователям самостоятельно настраивать сбор почты со сторонних почтовых ящиков. Поразбирался некоторое время, в итоге всё получилось. Плагин использует для сбора Fetchmail. Настройки хранит в базе MySQL, пользователи сами всё настраивают через веб интерфейс своего ящика.

В процессе настройки заметил в системном логе syslog строки, которых раньше там не было:

[Warning] Access denied for user 'user'@'localhost' (using password: YES)

Стало интересно, кто же это пытается подключиться к серверу Mariadb. Такого пользователя там не существует. Строки появляются строго раз в минуту.

Первым делом включил подробный лог запросов. Там обычно сразу видно, откуда идут подключения, если они сетевые. Добавил в настройки службы и перезапустил её:

general_log = 1
general_log_file = /var/log/mariadb/general.log

В general.log посыпались эти попытки:

32 Connect user@localhost on using Socket
32 Connect<>Access denied for user 'user'@'localhost' (using password: YES)

Как видно, подключение идёт через сокет, то есть локально. Но кто подключается, не понятно. На этом этапе я ещё не понимал, насколько задача непроста, так как изначально предположил, что будет нетрудно какими-то утилитами посмотреть, кто подключается. Сразу прикинул, что наверное тут поможет auditd или lsof. Они по идее могут отслеживать подключения к сокету.

С lsof всё относительно просто. Я уже раньше делал подборку с основными командами, где в том числе можно посмотреть подключения к сокетам. Смотрим открытый сокет mysql и подключения к нему:

# ss -lx | grep mysqld
# lsof /run/mysqld/mysqld.sock

Тут ничего полезного я не увидел, так как показывает результат в текущем моменте. Отследить вручную кратковременный запрос так нереально.

Дальше прошёл мучать ИИ. Те, кто с ним постоянно работают, наверное представляют, как он умеет водить по кругу. Он мне напредлагал кучу всего, но ничего не помогло. Я большие надежды возлагал на auditd, но так и не смог его настроить, чтобы отслеживать подключения к Mariadb через сокет. Не помог мне ни ChatGPT, ни DeepSeek, ни Perplexity. Все примерно одинаковое советовали: auditd, strace, ionotify, проверить кроны, таймеры и т.д.

Решил сам немного подумать. Посмотрел, когда появились первые записи в логе с этими подключениями. Оказалось, что сразу через минуту после установки мной пакета libdbd-mysql-perl. Он нужен для перлового скрипта для Fetchmail. Этот пакет - просто библиотека. Посмотрел, что он ставит в систему:

# dpkg -L libdbd-mysql-perl

Там нет ничего связанного со службами, кронами и вообще чем-либо, что может запускаться и работать. Это наблюдение меня окончательно сбило с толку. Я внимательно посмотрел ещё раз все логи, в том числе старые. Не было раньше подобных подключений. Появились ровно после установки этого пакета.

Не буду вас дальше томить. Ещё какое-то время я вручную изучал сервер. Всё, что там запущено. Грешил на мониторинг. Там работает prometheus-postfix-exporter. Но виновник оказался не он, хотя смотрел я в нужную сторону. Там же был установлен Monitorix, про который я недавно писал. И то ли он по умолчанию собирает метрики MySQL, то ли я включил и забыл, но факт в том, что именно он долбился в сокет с несуществующей учёткой, которая там записана по умолчанию.

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

#mysql