Я недавно обновил clamav с не уверен, какая версия, но все, что было текущим на EPEL 13 февраля, до 0.102.3. В предыдущей версии приходилось ставить TimeoutStartSec в файле systemd conf на 5 минут, чтобы он запустился без тайм-аута. В текущей версии AFAICT ~ никогда не запускается. Я пытаюсь понять, как запустить его на самом деле, и как довести его до успешного или неудачного состояния менее чем за несколько часов.
$sudo systemctl -l status clamd@amavisd
● clamd@amavisd.service - clamd scanner (amavisd) daemon
Loaded: loaded (/usr/lib/systemd/system/clamd@.service; enabled; vendor preset: disabled)
Active: activating (start) since Wed 2020-07-15 17:33:53 UTC; 4h 18min ago
Я продвигался вверх. Я бы установил тайм-аут 15 минут, затем 20 минут, затем 40 минут, затем 1,5 часа и, наконец, 4 часа. Среди множества любопытных вещей, вышеупомянутое все еще «активировалось» спустя долгое время после истечения 4 часов, но в конечном итоге все же не удалось:
Jul 15 17:23:29 ip-10-0-200-85 systemd: Starting clamd scanner (amavisd) daemon.
...
Jul 15 22:47:08 ip-10-0-200-85 systemd: clamd@amavisd.service failed.
Вот конфигурация systemd:
$cat /usr/lib/systemd/system/clamd@.service
[Unit]
Description = clamd scanner (%i) daemon
Documentation=man:clamd(8) man:clamd.conf(5) https://www.clamav.net/documents/
After = syslog.target nss-lookup.target network.target
[Service]
Type = forking
ExecStart = /usr/sbin/clamd -c /etc/clamd.d/%i.conf
# Reload the database
ExecReload=/bin/kill -USR2 $MAINPID
Restart = on-failure
TimeoutStartSec=240min
[Install]
WantedBy = multi-user.target
Последние записи журнала перед окончательным сбоем были
...
Jul 15 20:06:18 ip-10-0-200-85 clamd: LibClamAV debug: bytecode: registered ctx variable at 0x55ceb28157b0 (+744) id 7
Jul 15 20:06:18 ip-10-0-200-85 clamd: LibClamAV debug: bytecode debug: startup: bytecode execution in auto mode
Jul 15 20:06:18 ip-10-0-200-85 clamd: LibClamAV debug: interpreter bytecode run finished in 50106us, after executing 96 opcodes
Jul 15 20:06:18 ip-10-0-200-85 clamd: LibClamAV debug: Bytecode: disable status is 0
Jul 15 20:06:18 ip-10-0-200-85 clamd: LibClamAV debug: bytecode: JIT disabled
Jul 15 20:06:18 ip-10-0-200-85 clamd: LibClamAV debug: Cannot prepare for JIT, LLVM is not compiled or not linked
Jul 15 20:06:29 ip-10-0-200-85 clamd: LibClamAV debug: Bytecode: 0 bytecode prepared with JIT, 95 prepared with interpreter, 95 total
...
Я не был уверен, что это означало, что процесс запуска уже прошел 4-часовой тайм-аут и еще не завершился сам. В предыдущие короткие промежутки времени он просто перезапускал процесс запуска. Например, здесь таймер установлен на 20 минут:
Jul 15 16:12:32 ip-10-0-200-85 systemd: Starting clamd scanner (amavisd) daemon.
...
Jul 15 16:33:13 ip-10-0-200-85 systemd: clamd@amavisd.service start operation timed out. Terminating.
Jul 15 16:33:13 ip-10-0-200-85 systemd: Failed to start clamd scanner (amavisd) daemon.
Jul 15 16:33:13 ip-10-0-200-85 systemd: Unit clamd@amavisd.service entered failed state.
Jul 15 16:33:13 ip-10-0-200-85 systemd: clamd@amavisd.service failed.
Jul 15 16:33:14 ip-10-0-200-85 systemd: clamd@amavisd.service holdoff time over, scheduling restart.
Jul 15 16:33:14 ip-10-0-200-85 systemd: Starting clamd scanner (amavisd) daemon.
Учитывая, что через 20 минут после истечения 4-часового таймера, он не сработал. Failed to start clamd Я решил попробовать и пропустить через него почту. Почта действительно появилась в моем почтовом ящике с заголовком X-Virus-Scanned: amavisd-new at example.com, и похоже, что он что-то делает (хотя, признаюсь, я не уверен, что должны сказать эти файлы журнала):
Jul 15 21:57:07 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: Breaking command loop, mode is no longer MODE_COMMAND
Jul 15 21:57:07 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: Consumed entire command
Jul 15 21:57:07 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: Number of file descriptors polled: 1 fds
Jul 15 21:57:07 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: fds_poll_recv: timeout after 600 seconds
Jul 15 21:57:07 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: THRMGR: queue (single) crossed low threshold -> signaling
Jul 15 21:57:07 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: THRMGR: queue (bulk) crossed low threshold -> signaling
Jul 15 21:57:10 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: Finished scanthread
Jul 15 21:57:10 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: Scanthread: connection shut down (FD 10)
Jul 15 21:57:10 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: THRMGR: queue (single) crossed low threshold -> signaling
Jul 15 21:57:10 ip-10-0-200-85.eu-central-1.compute.internal clamd[16152]: THRMGR: queue (bulk) crossed low threshold -> signaling
Я просто позволил ему поработать, продолжая работать в «активированном» состоянии, но в конечном итоге он отказал через 5 часов 15 минут (опять же, против 4-часового таймера ¯_ (ツ) _ / ¯):
Jul 15 17:23:29 ip-10-0-200-85 systemd: Starting clamd scanner (amavisd) daemon...
...
Jul 15 22:47:06 ip-10-0-200-85 systemd: clamd@amavisd.service start operation timed out. Terminating.
Jul 15 22:47:08 ip-10-0-200-85 systemd: Failed to start clamd scanner (amavisd) daemon.
Jul 15 22:47:08 ip-10-0-200-85 systemd: Unit clamd@amavisd.service entered failed state.
Jul 15 22:47:08 ip-10-0-200-85 systemd: clamd@amavisd.service failed.
Jul 15 22:47:08 ip-10-0-200-85 systemd: clamd@amavisd.service holdoff time over, scheduling restart.
Итак, как я сказал в начале, я пытаюсь понять, как заставить это действительно начаться - и пока работаю над этим, пытаюсь выяснить, как заставить его выйти из строя менее чем за часы. Очевидно, что можно постоянно увеличивать таймер, но я не хочу ждать 5, 6, 7 часов между тестами, если есть лучший способ сделать это или что-то очевидное, что мне не хватает.
Также я посмотрел на Мои заметки о том, как заставить ClamAV работать на Centos 7 [на самом деле это не мои заметки, это просто так]. Там есть кое-что интересное: установка хорошего уровня, ограничения ЦП и памяти, но они, похоже, еще больше замедлят работу.
TIA за любой помощью / подсказками / предложениями.
В конечном итоге, похоже, это была проблема с памятью. Служба работала на AWS EC2 t2.nano (т. Е. С 500 МБ ОЗУ) с 2 ГБ подкачки. Раньше это работало, но очевидно, что в какой-то момент за последние шесть месяцев ClamAV просто ... нужно было больше. Я переключил тип экземпляра на t2.micro (1 ГБ ОЗУ), и он просто заработал. Возможно, для некоторых людей все же было бы неплохо выяснить, как заставить clamd использовать больше подкачки / меньше реальной памяти, но в большинстве случаев достаточно просто убедиться, что у вас есть хотя бы 1 ГБ ОЗУ.