Посмотрим, нет ли блокировок почтовых ящиков:
# cd /var/spool/mail
# ls *.lock
lz.lock
#
Ага, один ящик заблокирован (здесь я описываю на примере моего ящика lz, хотя в жизни это были ящики других пользователей). Посмотрим, кто его использует:
# fuser -v lz
USER PID ACCESS COMMAND
lz: lz 20384 F.... pop3
lz 20476 F.... procmail
#
Похоже, процесс pop3-сервера занял ящик, поэтому procmail не может открыть его на запись. Проверим:
# lsof -p 20384
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
...
pop3 20384 lz 9uR REG 253,3 11922701 16680817 /var/spool/mail/lz
(здесь число послее опции -p команды lsof - это PID, который вывела команда fuser; и я опустил все строки в выводе lsof, кроме интересующей меня).
Действительно, файл заблокирован на чтение (о чем говорит большая буква R в колонке FD). Но с какой стати процесс pop3 это сделал? Казалось бы, он должен выдать клиенту все сообщения и "отвалить". С помощью strace'а я посмотрел, чем был занят процесс pop3 - оказалось, периодически получает от клиента команды NOOP, и все. Зачем клиент посылает эти команды и не отключается? Я проверил поведение Outlook Express'а на своем компьютере - как и ожидалось, он подключался, забирал почту и отключался, т.е. не висел и команд NOOP не посылал.
Далее я заметил, что пользователи, чьи ящики таким странным образом блокировались, были все время одни и те же. Это побудило меня тщательно обследовать их компьютеры. И тут на сцене появился герой этой заметки - антивирус Касперского. На компьютерах всех пользователей, страдавших от блокировки, работал почтовый антивирус. Отключили почтовый антивирус - проблема ушла.
И черт с этим почтовым антивирусом, все равно почту проверяет ClamAV
No comments:
Post a Comment