Зачем нужен clamav-daemon.socket?

Debian 11. Недавно при обновлении одного почтового сервера столкнулся с тем, что перестал запускаться clamd. Проблема оказалась в том, что обновленный clamd не обращает внимание на сокет, указанный в его конфиге /etc/clamav/clamd.conf Вот для этих целей и используют clamav-daemon.socket.

Как правильно отключить clamav-daemon.socket чтобы #$%^&* systemd не пытался занять порт clamd?

systemctl mask clamav-daemon.socket можешь попробовать. На всякий случай - я не использовал ни разу clamav, поэтому не знаю что там за сокет и как оно там в дистрах сконфигурировано.

Сокет у тебя должен быть один - либо созданный из самого clamav, либо созданный из systemd(и переданный в clamav). Второе рулится из юнитов, первое - опциями/конфигом clamav(если там есть такая возможность).

На кой нужен пустой файл /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/clamav-daemon.socket

Возможно отключает(точнее, не включает) создание сокета из системд.

На кой нужен пустой файл /var/lib/systemd/deb-systemd-helper-enabled/sockets.target.wants/clamav-daemon.socket

sockets.target.wants/clamav-daemon.socket

sockets.target wants clamav-daemon.socket

Какая версия clamav?

Если запуск через .socket это режим inetd, то stdin/stdout это сокет. Я не могу представить себе это с clamd.

Ну я тоже так думал, но вот мантейнер в убунте видимо с другой планеты.

но вот мантейнер в убунте видимо с другой планеты.

Космонавт же! Имхо всё логично получается.

clamav 1.0.7+dfsg-1~deb11u2

Сокет активация в systemd устроена так: systemd pid 1 создаёт слушающий сокет, статус сокет юнита становится listening. pid 1 опрашивает (poll) этот сокет на чтение. Когда сокет становится готовым для чтения (т.е. в очереди сокета появился входящий коннект), pid 1 перестаёт его опрашивать, запускает юнит сервиса (указанного в юните сокета), передаёт копию слушающего сокета ему (дублирование файлового дескриптора при форке). В результате на один и тот же сокет указывают файловые дескрипторы двух процессов: pid 1 и процесс сервиса. Сокет юнит переходит в состояние running. Посмотреть статусы сокет юнитов можно systemctl list-units --type socket.

Когда сервис юнит сервиса останавливается (например, демон упал), сокет юнит опять переходит в состояние listening и pid 1 снова начинает его опрашивать на чтение.

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

Судя по одинаковым inode 9623099 это один и тот же сокет. Но может быть из-за долгого стартапа сервиса клиент не дожидается ответа и сам закрывает коннект?

Можно отключить сокет юнит systemctl disable foobar.socket --now, включить сервис юнит systemctl enable foobar.service --now, тогда сервис будет запускаться без сокет активации.

Спасибо за интимные подпробности про sd_listen_fds.

Я все больше и больше понимаю, что для clamd, который стартует десятки секунд использование .socket противопоказано.

Проблема наблюдается очень редко - раз в несколько месяцев и пока неясна причина.

В дистрибутиве без systemd таких проблем небыло никогда.

Проблема оказалась в том, что обновленный clamd не обращает внимание на сокет, указанный в его конфиге /etc/clamav/clamd.conf

А баг отрепортить цисковцам не судьба, если это правда? Надо костылить? Санкции санкциями, но неужели в дебиановском комъюнити больше никого?

Да это правда. Да и debian 12 это наблюдалось.

https://serverfault.com/questions/1149901/debian-12-cant-get-clamav-to-listen-on-tcp-3310

По ходу использование сокет-активации приводит к проблемам. Отуда и задержки, потери запросов. Судя по выводу netstat и lsof, systemd занимает порт 3310 и передает его clamd после запуска, это и вызывает проблемы с обработкой запросов. Нужно остановить и отключить сокет-юнит, Убедится, что сервис clamd настроен на запуск напрямую - (обычно в файле /etc/clamav/clamd.conf) указан порт 3310, и что сервис clamd запускается самостоятельно, а не через сокет-активацию. Перезапустить сервис.

Убедится, что сервис clamd настроен на запуск напрямую - (обычно в файле /etc/clamav/clamd.conf) указан порт 3310,

У меня так и было. При обновлении clamav перестает обращать внимание на порт, указанный в /etc/clamav/clamd.conf.

В systemd-юните clamav-daemon.service могут быть указаны параметры запуска, которые переопределяют настройки из /etc/clamav/clamd.conf. Например, в юните может быть указан другой порт или сокет. Запусти clamd вручную с указанием конфигурационного файла и проверь вывод: sudo -u clamav /usr/sbin/clamd –foreground –config-file=/etc/clamav/clamd.conf Если clamd запускается корректно и слушает указанный порт, значит проблема в systemd-юните. Если нет — проверяй конфиг на ошибки.

Если clamd запускается корректно и слушает указанный порт, значит проблема в systemd-юните.

Я ему стриженый, а он мне бритый. Система работала месяцами, это случилось при стандартном обновлении debian.