Назад | Перейти на главную страницу

Yum-cron не может отправить письмо root

Я пытаюсь исследовать проблему на одном из наших серверов CentOS 7, для которой yum-cron не может отправить электронное письмо root с результатом выполненных операций.

Всегда выдает эту ошибку:

Не удалось отправить электронное письмо на localhost: [Errno 111] В соединении отказано

Однако у нас есть другие серверы с такой же конфигурацией, и это единственный сервер, на котором наблюдается такая проблема.

Здесь yum-cron.conf содержание:

[commands]
#  What kind of update to use:
# default                            = yum upgrade
# security                           = yum --security upgrade
# security-severity:Critical         = yum --sec-severity=Critical upgrade
# minimal                            = yum --bugfix update-minimal
# minimal-security                   = yum --security update-minimal
# minimal-security-severity:Critical =  --sec-severity=Critical update-minimal
update_cmd = default

# Whether a message should be emitted when updates are available,
# were downloaded, or applied.
update_messages = yes

# Whether updates should be downloaded when they are available.
download_updates = yes

# Whether updates should be applied when they are available.  Note
# that download_updates must also be yes for the update to be applied.
apply_updates = yes

# Maximum amout of time to randomly sleep, in minutes.  The program
# will sleep for a random amount of time between 0 and random_sleep
# minutes before running.  This is useful for e.g. staggering the
# times that multiple systems will access update servers.  If
# random_sleep is 0 or negative, the program will run immediately.
# 6*60 = 360
random_sleep = 360


[emitters]
# Name to use for this system in messages that are emitted.  If
# system_name is None, the hostname will be used.
system_name = None

# How to send messages.  Valid options are stdio and email.  If
# emit_via includes stdio, messages will be sent to stdout; this is useful
# to have cron send the messages.  If emit_via includes email, this
# program will send email itself according to the configured options.
# If emit_via is None or left blank, no messages will be sent.
emit_via = email

# The width, in characters, that messages that are emitted should be
# formatted to.
output_width = 80


[email]
# The address to send email messages from.
email_from = root

# List of addresses to send messages to.
email_to = root

# Name of the host to connect to to send email messages.
email_host = localhost


[groups]
# NOTE: This only works when group_command != objects, which is now the default
# List of groups to update
group_list = None

# The types of group packages to install
group_package_types = mandatory, default

[base]
# This section overrides yum.conf

# Use this to filter Yum core messages
# -4: critical
# -3: critical+errors
# -2: critical+errors+warnings (default)
debuglevel = -2

# skip_broken = True
mdpolicy = group:main

# Uncomment to auto-import new gpg keys (dangerous)
# assumeyes = True

Я дважды проверил, и он идентичен файлу конфигурации на других серверах.

Также на всех серверах есть postfix установлен как почтовый сервер, который использует sendgrid как smtp relay.

Наконец, на все серверы, отправляя электронные письма root вручную через mail команда работает без ошибок.

Что я должен проверить, чтобы cron правильно отправлял электронные письма для root?

РЕДАКТИРОВАТЬ:

После некоторого тестирования я заметил, что на сервере с проблемой нет TCP-порта 25:

[root@srv1 ~]# ss -tnlp | grep :25
[root@srv1 ~]#

а на другом сервере я получаю:

[root@srv2 ~]# ss -tnlp | grep :25
LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=768,fd=13))
[root@srv2 ~]#

где процесс с PID 768 /usr/libexec/postfix/master -w.

Затем я проверил, какие процессы активны для postfix service, и на первом сервере я получаю:

[root@srv1 ~]# service postfix status
Redirecting to /bin/systemctl status  postfix.service
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2017-01-10 09:18:55 CET; 5min ago
  Process: 17409 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 17431 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 17428 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)
  Process: 17421 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)
 Main PID: 17503 (master)
   CGroup: /system.slice/postfix.service
           ├─17503 /usr/libexec/postfix/master -w
           ├─17504 pickup -l -t unix -u
           └─17505 qmgr -l -t unix -u

а на втором выходе:

[root@srv2 ~]# service postfix status
Redirecting to /bin/systemctl status  postfix.service
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2016-12-28 16:34:19 CET; 1 weeks 5 days ago
 Main PID: 768 (master)
   CGroup: /system.slice/postfix.service
           ├─ 768 /usr/libexec/postfix/master -w
           ├─ 770 qmgr -l -t unix -u
           ├─8185 pickup -l -t unix -u
           └─9148 tlsmgr -l -t unix -u

Так казалось бы на первом сервере tlsmgr не запускается вообще, однако я не могу найти никаких ошибок в журналах.

В конце концов я обнаружил, что это не проблема yum-cron а скорее с конфигурацией postfix сам.

Фактически, на первом сервере master.cf файл был похож:

# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
#smtp      inet  n       -       n       -       -       smtpd
#smtp      inet  n       -       n       -       1       postscreen
#smtpd     pass  -       -       n       -       -       smtpd
#dnsblog   unix  -       -       n       -       0       dnsblog
#tlsproxy  unix  -       -       n       -       0       tlsproxy
submission inet n       -       n       -       -       smtpd
[...]

а на втором сервере это было:

# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd
#smtp      inet  n       -       n       -       1       postscreen
#smtpd     pass  -       -       n       -       -       smtpd
#dnsblog   unix  -       -       n       -       0       dnsblog
#tlsproxy  unix  -       -       n       -       0       tlsproxy
#submission inet n       -       n       -       -       smtpd
[...]

и установив первый файл как второй, то есть раскомментировав первый smtp линия и удаление submission line, у меня все заработало, как ожидалось.