On Thu, Sep 28, 2023 at 05:32:35PM +0700, Max Nikulin wrote:
> On 26/09/2023 21:43, Eugene Berdnikov wrote:
> > On Tue, Sep 12, 2023 at 10:55:46PM +0300, Eugene Berdnikov wrote:
> > Но не тут-то было: сегодня 4 раза подряд rsyslogd не запустился... :)
> > На том же хосте, где 2 недели назад проверялся orphan-sysvinit-scripts.
>
> А в консоль он что-нибудь пишет, когда не может запуститься?
Нет.
> Останавливается перед этим нормально?
Ммм... не знаю. Он при остановке что-то странное делает.
У него при работе открыт некий сокет на fd=1,
lr-x------ 1 root root 64 сен 28 16:30 0 -> /dev/urandom
lrwx------ 1 root root 64 сен 28 16:30 1 -> 'socket:[34753352]'
...
и он перед экзитом выполняет такой код:
[pid 848] --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=1428154,
si_uid=0} ---
[pid 848] gettid() = 848
[pid 848] getpid() = 848
...
[pid 848] kill(848, SIGTTOU) = 0
[pid 848] --- SIGTTOU {si_signo=SIGTTOU, si_code=SI_USER, si_pid=848,
si_uid=0} ---
[pid 848] sigreturn({mask=[]}) = 0
[pid 848] send(1, "<46>Sep 28 16:37:26 rsyslogd: [origin
software=\"rsyslogd\" swVersion=\"8.2308.0\" x-pid=\"848\"
x-info=\"https://www.rsyslog.com\";] exiting on signal 15.", 146, MSG_NOSIGNAL)
= -1 ECONNREFUSED (В соединении отказано)
[pid 848] close(1) = 0
[pid 848] socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 1
[pid 848] connect(1, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = -1
ENOENT (Нет такого файла или каталога)
[pid 848] close(1) = 0
Возможно, этот сокет с fd=1 используется для взаимодействия со своими же
тредами, но поскольку на send() возвращается ECONNREFUSED, то скорее всего
тред-писатель уже не слушает, и потому в логе сообщения об экзите нет.
Зачем далее открывается ещё один сокет, и делается попытка соединиться
с /dev/log (это самим-то rsyslogd, да ещё по получении SIGTERM!),
я не понимаю. И, честно говоря, совершенно не горю желанием разбираться,
поскольку, повторюсь, страшно подумать, что там внутри...
Хотя может я просто чайник и не способен понять логику из трейса.
Например, зачем самому себе посылать SIGTTOU, причём внутри обработчика
сигнала (поскольку далее идёт sigreturn()).
> > > В чём была проблема -- мне тогда
> > > докопаться не удалось (уже не помню, почему, кажется, под strace эта
> > > зараза всегда успешно работала, а без strace процесс исчезал, не
> > > оставляя
> > > ни корки, ни других следов).
>
> Либо не крэш, либо не может запись core файла подавлена. Как минимум 2 места
> есть: rlimits и sysctl kernel.core*, описано в core(5).
# sysctl -a | fgrep kernel.core
kernel.core_pattern = core
kernel.core_pipe_limit = 0
kernel.core_uses_pid = 0
# ulimit -c
unlimited
# limit coredumpsize
coredumpsize unlimited
Перезапускаем (/etc/init.d/rsyslog restart) и ура, с первого раза поймали.
# ps -C rsyslogd fww
PID TTY STAT TIME COMMAND
#
# ls -al core
ls: невозможно получить доступ к 'core': Нет такого файла или каталога
# find / -mount -name core
#
А пока я всё это копипастил сюда, запускаемый по крону монитор отловил
факт отсутствия процесса и запустил его:
# ps -C rsyslogd fww
PID TTY STAT TIME COMMAND
1053061 ? Ssl 0:00 /usr/sbin/rsyslogd
Кстати, с тех пор как я писал сюда об "успешных" экспериментах по запуску
rsyslogd, тот опять обновился, и нынче его версия 8.2308.0-1, для i386.
--
Eugene Berdnikov
