У меня здесь довольно неприятная проблема. Я тестировал приложение и создал несколько тестовых сообщений на поддельные адреса электронной почты (не говоря уже о том, что мой сервер не настроен на отправку электронной почты в любом случае). Конечно, sendmail
не удается отправить эти сообщения, и они застряли в sendmail
очереди. Я хочу вручную удалить сообщения, которые накапливаются в очереди, вместо того, чтобы ждать 5 дней, которые sendmail
обычно требуются для прекращения повторных попыток.
Я использую Ubuntu 10.04 и /var/spool/mqueue/
это каталог, в котором все инструкции, которые я прочитал, говорят, что электронные письма, находящиеся в очереди, хранятся. Когда я удаляю файлы в этом каталоге, sendmail
перестает пытаться обрабатывать электронные письма до тех пор, пока не запустится то, что кажется скриптом cron, и не заполнит этот каталог сообщениями, которые я не хочу отправлять. Вот несколько строк из моего syslog
:
Jun 2 17:35:19 sajo-laptop sm-mta[9367]: o530SlbK009365: to=, ctladdr= (33/33), delay=00:06:27, xdelay=00:06:22, mailer=esmtp, pri=120418, relay=e.mx.mail.yahoo.com. [67.195.168.230], dsn=4.0.0, stat=Deferred: Connection timed out with e.mx.mail.yahoo.com.
Jun 2 17:35:48 sajo-laptop sm-mta[9149]: o4VHn3cw003597: to=, ctladdr= (33/33), delay=2+06:46:45, xdelay=00:34:12, mailer=esmtp, pri=3540649, relay=mx2.hotmail.com. [65.54.188.94], dsn=4.0.0, stat=Deferred: Connection timed out with mx2.hotmail.com.
Jun 2 17:39:02 sajo-laptop CRON[9510]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)
Jun 2 17:39:43 sajo-laptop sm-mta[9372]: o52LHK4s007585: to=, ctladdr= (33/33), delay=03:22:18, xdelay=00:06:28, mailer=esmtp, pri=1470404, relay=c.mx.mail.yahoo.com. [206.190.54.127], dsn=4.0.0, stat=Deferred: Connection timed out with c.mx.mail.yahoo.com.
Jun 2 17:39:50 sajo-laptop sm-mta[9149]: o51I8ieV004377: to=, ctladdr= (33/33), delay=1+06:31:06, xdelay=00:03:57, mailer=esmtp, pri=6601668, relay=alt4.gmail-smtp-in.l.google.com. [74.125.79.114], dsn=4.0.0, stat=Deferred: Connection timed out with alt4.gmail-smtp-in.l.google.com.
Jun 2 17:40:01 sajo-laptop CRON[9523]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Кто-нибудь знает, как я могу навсегда избавиться от этих сообщений? Как примечание, я также хотел бы знать, есть ли способ настроить sendmail
«фальшивую» отправку электронной почты. Есть?
Ответы:
Сообщения, которые были отправлены или пытаются быть отправлены, хранятся в
/var/spool/mqueue
. Сообщения, которые Sendmail еще не пытался поставить в очередь, можно найти в/var/spool/mqueue-client
.Попробуйте это (я полагаю, вы хотите избавиться от всех сообщений в очереди):
rm /var/spool/mqueue/*
rm /var/spool/mqueue-client/*
.Это очистит нашу папку (и) вашей очереди, пока система не получит другое сообщение. Вы можете выполнить двойную проверку, запустив
mailq
(обе папки очереди) илиsendmail -bp
(только папку очереди).ПРИМЕЧАНИЕ. В большинстве дистрибутивов Linux вы можете запускать / останавливать сервисы с помощью
service sendmail <start|stop|restart>
или/etc/init.d/sendmail <start|stop|restart>
. Обе опции имеют много других флагов состояния, которые можно наблюдать, набрав команду и службу без флагов состояния.источник
no matches found
). Поэтому яchmod
отредактировал папки777
и смог удалить их содержимое.Вы часто найдете предложение удалить файлы из каталога mqueue Sendmail, например
rm /var/spool/mqueue/*
или хуже (rm -rf
и т. Д.). ИМХО, это довольно опасно. Во многих случаях это будет работать, но я рекомендую пристегнуть ремни безопасности. Простое удаление всех файлов из mqueue может привести к удалению законных сообщений.Остановка Sendmail перед удалением сообщений в очереди - хороший совет, особенно если необходимо удалить много сообщений. Однако, если нужно удалить только несколько сообщений или если очередь очищается на регулярной основе, например, с помощью задания cron, фактически нет необходимости останавливать Sendmail. В худшем случае одно из сообщений будет помещено в очередь, которое почти наверняка будет удалено при повторной попытке.
Напротив, остановка Sendmail (например, в Ubuntu с помощью
service sendmail stop
) может быть недостаточной. Даже когда остановлено, некоторые (дочерние) процессы могут все еще работать. Нужно подождать, пока они закончат (рекомендуется) или убить их.Для безопасного удаления сообщений из mqueue вам нужны идентификаторы очереди сообщений. Идентификаторы отображаются в журнале после "sm-mta [...]:". Идентификаторы из журнала выписки являются
o530SlbK009365
,o4VHn3cw003597
... Для каждого из идентификаторов 2 файлов , хранящихся в mqueue, один , начиная с «QF», а другой , начиная с «ДФ».mailq
обычно используется для отображения содержимого очереди. Показывает идентификаторы в первом столбце. Кроме того, вам следует ознакомитьсяmailq
с выходными данными, поскольку они также показывают, является ли сообщение активным / обрабатываемым в данный момент. НапримерВ этом примере в
oBDDuKAB023946
настоящее время обрабатывается сообщение с идентификатором , которое отображается с добавленной звездочкой. Другие сообщения безопасны для удаления. Например, для удаления сообщения с идентификаторомoBAEMuV8000429
используйтеБолее универсальный подход к удалению сообщений из очереди предоставлен Брэндоном Хатчинсоном в статье «Удаление почты из почтовой очереди» . Брэндон также включает в себя сценарии для удаления сообщений на основе доменной части, адреса электронной почты и т. Д. Сценарии Брэндона очень полезны для регулярной очистки или массового удаления.
Тем не менее, даже сценарии Брэндона не заботятся о статусе сообщений. Тем не менее, это легко добавить. Включить в начале своих сценариев
Затем в начале подпрограммы «wanted» добавьте проверку, чтобы пропустить активные сообщения, например, с помощью
НТН. И не забудьте сделать резервные копии :-)
источник
У меня была такая же проблема, и я обнаружил, что есть 2 папки с сообщениями в очереди. Папка / var / spool / clientmqueue / содержала сообщения, которые заканчивались в / var / spool / mqueue /, если их не удалось доставить. Удаление файлов из обеих папок было необходимо для решения проблемы.
rm -f / var / spool / clientmqueue / * rm -f / var / spool / mqueue / *
источник
Я не думаю, что это работа скрипта cron, это скорее проблема приложения или что-то, связанное с самой sendmail; в любом случае, чтобы исключить любую работу cron, вы можете просто остановиться
crond
и посмотреть, происходит ли это.источник
Мне удалось сделать это с помощью этого сценария Bash
источник
echo
и извлекать вывод сказанногоecho
для использования в качестве параметраrm
. Даже игнорируя безвозмездные вилкиsudo
иrm
, этот подобстрел просто расточительный.sudo find /var/spool/mqueue -maxdepth 1 -delete
. Я считаю важным указать, что является проблематичным с вашим сценарием, в частности. Извиняюсь за отсутствие такта.