На сервере Seafile в логах сборщика мусора встретил странные ошибки:
2025-11-02 22:26:21 ../../common/seaf-db.c(867): Failed to connect to MySQL: Can't connect to server on '127.0.0.1' (110)
MySQL работает нормально, Seafile тоже работает, а ошибки есть. Начал гуглить и нашёл интересный кейс:
https://forum.seafile.com/t/seafile-pro-7-1-3-failed-to-connect-to-mysql/11827
Не я один нарвался на такую ошибку, более того, ошибка проявляется и про использовании seaf-fuse, что совсем неудобно. При этом ломается точка монтирования.
В статье приводится решение проблемы: установить значения net.ipv4.tcp_tw_reuse и net.ipv4.tcp_tw_recycle в 1. Давайте попробуем.
В /etc/sysctl.conf добавляем:
net.ipv4.tcp_tw_reuse = 1Выполняем:
sudo sysctl -pПерезагрузимся на всякий случай.
Параметр tcp_tw_recycle не будем использовать по просто причине: net.ipv4.tcp_tw_recycle был удалён из ядра Linux 4.12 в 2017 году. Если его применить в более новой версии ядра, то получим ошибку:
sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No such file or directory
tcp_tw_reuse
Параметр tcp_tw_reuse помогает избежать нехватки свободных портов на сервере. Когда вы закрываете TCP-соединение, его порт ненадолго блокируется в состоянии TIME_WAIT. Если сервер создаёт много коротких подключений, свободные порты быстро заканчиваются. Включив tcp_tw_reuse = 1, вы разрешаете системе повторно использовать эти порты для новых исходящих соединений, не дожидаясь их полной разблокировки. Это ускоряет работу и решает проблему нехватки портов.
В случае Seafile, раз он постоянно создаёт отдельные соединения к MySQL (зря, конечно), использовать этот параметр кажется разумным.
tcp_tw_recycle
Параметр tcp_tw_recycle ускоряет освобождение портов из состояния TIME_WAIT. По умолчанию порт остается заблокированным 2 минуты. При включении tcp_tw_recycle система сокращает это время, подбирая его под вашу сеть. Однако этот параметр опасен. Он может вызывать проблемы при работе через NAT (например, в облаках или корпоративных сетях), когда соединения начинают необъяснимо обрываться. Эти сбои сложно диагностировать, поэтому использовать tcp_tw_recycle не рекомендуется.
Продолжение
Кому-то помогла данная настройка, мне — нет. Посмотрел логи в MariaDB, там ошибка:
Aborted connection 23793 to db: 'seafile-seahub' user: 'seafile' host: '192.168.1.12' (Got an error reading communication packets)
[Warning] Aborted connection 19443 to db: 'seafile-db' user: 'seafile' host: '192.168.1.12' (Got an error reading communication packets)
[Warning] Aborted connection 23961 to db: 'seafile-ccnet' user: 'seafile' host: '192.168.1.12' (Got an error reading communication packets)
https://forum.seafile.com/t/mysql-db-error-reading-communication-packets/24522
Пишут что имеются баги в компонентах Seafile, когда компоненты не закрывают соединения с БД. Говорят, что это не критично.
Однако, я считаю, что это критично. Потому как восстановление не отрабатывает так как нужно. Меня это не устраивает. Попробую увеличить количество соединений с БД, увеличить таймауты, подкрутить параметры.
2025-11-05 09:10:09 ../../common/seaf-db.c(867): Failed to connect to MySQL: Can't connect to server on '127.0.0.1' (110)
2025-11-05 09:10:09 fsck.c(614): Repo 0b3ddb40 doesn't exist
MariaDB — настройка конфигурационных параметров в TrueNAS
И снова ошибка на том же месте. Однако, проанализировав содержимое библиотеки стало понятно, сто repair отваливается от БД на больших файлах. Там просто был один ролик на несколько гигабайт. Вероятно, нужно повышать какой-то параметр в размере ещё больше.
Файл мне был не нужен, я его стёр, в итоге восстановление заработало без сбоев.
