На сервере 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 не рекомендуется.
