Почему завершились postfix и dovecot ?

[grumbler]

Странная ситуация.
Altlinux p7 (7.0.5)
Вчера в 19:05:02 postfix и dovecot завершились, как будто кто-то выполнил инит-скрипты с командой stop. В /var/log/maillog:
Jan 19 19:05:02 labara-host postfix/postfix-script[58724]: stopping the Postfix mail system
Jan 19 19:05:02 labara-host postfix/master[60822]: terminating on signal 15

Я этого не делал, в логах информации нет (смотрел  /var/log/ahttpd/access.log, /var/log/daemons/{errors,warnings,info}, /var/log/secure, /var/log/auth/all, /var/log/messages
даже в /var/log/kernel/{errors,warnings,info} заглянул.

Как найти причину остановки почтовых демонов?

[asy]

А можно несколько строк лога раньше увидеть ? Собственно, интересует время, не было ли синхронизации на какой-то большой интервал.

[grumbler]

А можно несколько строк лога раньше увидеть ? Собственно, интересует время, не было ли синхронизации на какой-то большой интервал.

Просмотрел на 2 часа перед событием - в логах скачков нет.
Ещё я удивился, что в логах нет ни единого сообщения от ntpd. Как он информирует о своей активности, это ведь openntpd из OpenBSD, а в ней ntpd вполне сообщает о себе.

[ruslandh]

А nttpd запущен?

[grumbler]

С ntpd разобрался - syslogd пишет его сообщения в /var/log/daemon/*
Видимо, часы идут точно и давно не было нужды синхронизировать время.

[ruslandh]

terminating on signal 15

Странно это - 15-й сигнал - это-же kill. кто-то его послал. или в самом скрипте останова используется kill?
А не мог какой-нибудь скрипт из cron это сделать? Допустим из "месячных". Или logrotate для архивирования логов?

[grumbler]

Странно это - 15-й сигнал - это-же kill. кто-то его послал. или в самом скрипте останова используется kill?
А не мог какой-нибудь скрипт из cron это сделать? Допустим из "месячных". Или logrotate для архивирования логов?

В /usr/libexec/postfix/postfix-script в функции stop() выполняется kill с сигналом по умолчанию, то есть SIGTERM.
В логах крона нет ничего в это время (забыл написать сразу).

Я потому и спрашиваю, что не смог найти в логах явное прибитие процессов.

Есть у меня подозрение, что виновато обновление. Но если это так, в postinstall-скрипте демоны должны рестартовать, а не останавливаться.

[ruslandh]

Есть у меня подозрение, что виновато обновление.

Скорей всего так и есть. На спек надо взглянуть.

[grumbler]

На спек надо взглянуть.

pre/post скрипты есть в самих пакетах:

Код: [Выделить]

[root@labara-host ~]# rpm -q --scripts alterator-postfix-dovecot
postinstall scriptlet (through /bin/sh):
if [ "$1" -eq 1 ]; then
        /usr/lib/alterator/hooks/net-domain.d/20-postfix-dovecot
        /etc/hooks/hostname.d/22-postfix
        /etc/hooks/hostname.d/23-dovecot
fi
[root@labara-host ~]# rpm -q --scripts postfix-tls
postinstall scriptlet (through /bin/sh):
for n in smtp smtpd; do
      ln -snf "$n"-tls /usr/libexec/postfix/"$n"
done
sed -i 's/^#\(.*tls\)/\1/' /usr/libexec/postfix/postfix-files
/usr/libexec/postfix/post-install upgrade-package
preuninstall scriptlet (through /bin/sh):
if [ $1 = 0 ]; then   
        for n in smtp smtpd; do
              ln -snf "$n"-std /usr/libexec/postfix/"$n"
        done
        sed -i 's/[^#]*tls/#&/' /usr/libexec/postfix/postfix-files
fi
[root@labara-host ~]# rpm -q --scripts postfix
preinstall scriptlet (through /bin/sh):
/usr/sbin/groupadd -r -f postdrop
/usr/sbin/groupadd -r -f postfix
/usr/sbin/groupadd -r -f postman
/usr/sbin/groupadd -r -f mailadm
/usr/sbin/useradd -r -n -g postfix -d /var/spool/postfix -s /dev/null -c postfix postfix >/dev/null 2>&1 ||:
/usr/sbin/useradd -r -n -g postman -d /dev/null -s /dev/null -c postman postman >/dev/null 2>&1 ||:

rm -f /var/run/postfix.restart
if [ $1 -ge 2 ]; then
        /etc/rc.d/init.d/postfix status >/dev/null 2>&1 && /etc/rc.d/init.d/postfix stop && touch /var/run/postfix.restart ||:
        if [ ! -f /usr/libexec/postfix/postqueue/postqueue -a \
               -f /usr/sbin/postqueue -a \
             ! -L /usr/sbin/postqueue ]; then
                mkdir -pm755 /usr/libexec/postfix/postqueue &&
                cp -pf /usr/sbin/postqueue /usr/libexec/postfix/postqueue/
        fi
        /usr/sbin/control-dump postfix postqueue
fi

oua=/usr/sbin/update-alternatives
if [ -x "$oua" ]; then
        "$oua" --remove aliases /etc/postfix/aliases >/dev/null 2>&1 ||:
fi
postinstall scriptlet (through /bin/sh):
if [ $1 = 1 ]; then   
        /sbin/chkconfig --add postfix
fi
rm -f /etc/postfix/{access,aliases,canonical,relocated,transport,virtual}.{,c}db
/usr/libexec/postfix/post-install \
        config_directory=/etc/postfix \
        daemon_directory=/usr/libexec/postfix \
        upgrade-package
if [ $1 -ge 2 ]; then
        ALIASES=/etc/postfix/aliases /usr/share/sendmail-common/rebuild_aliases
        /etc/chroot.d/postfix.all --force
        /usr/sbin/control-restore postfix postqueue
else
        /usr/sbin/control postfix local
        /usr/sbin/control postqueue public
fi
if [ -f /var/run/postfix.restart ]; then
        rm -f /var/run/postfix.restart
        /etc/rc.d/init.d/postfix start ||:
fi
preuninstall scriptlet (through /bin/sh):
if [ $1 = 0 ]; then   
        /etc/rc.d/init.d/postfix condstop
        /sbin/chkconfig --del postfix
        rm -f /var/spool/postfix/lib/* /var/spool/postfix/etc/* /var/spool/postfix/var/yp/binding/*
fi

[ruslandh]

Что-то похоже на
https://bugzilla.altlinux.org/show_bug.cgi?id=31363

А вот и баг:
https://bugzilla.altlinux.org/show_bug.cgi?id=21620

[grumbler]

А вот и баг:
https://bugzilla.altlinux.org/show_bug.cgi?id=21620

Спасибо. Действительно, поведение практически идентичное описанному в баге. Я там прокомментировал.