Re: devuan
Eugene Berdnikov wrote:
> 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 используется для взаимодействия со своими же
Это явно результат вызова openlog() где-то внутри syslog().
> тредами, но поскольку на send() возвращается ECONNREFUSED, то скорее всего
> тред-писатель уже не слушает, и потому в логе сообщения об экзите нет.
> Зачем далее открывается ещё один сокет, и делается попытка соединиться
> с /dev/log (это самим-то rsyslogd, да ещё по получении SIGTERM!),
> я не понимаю. И, честно говоря, совершенно не горю желанием разбираться,
> поскольку, повторюсь, страшно подумать, что там внутри...
> Хотя может я просто чайник и не способен понять логику из трейса.
> Например, зачем самому себе посылать SIGTTOU, причём внутри обработчика
> сигнала (поскольку далее идёт sigreturn()).
Зачем - это можно понять из коментария пустого обработчика сигнала:
--- cut ---
static void
hdlr_sigttin_ou(void)
{
/* this is just a dummy to care for our sigttin input
* module cancel interface and sigttou internal message
* notificaton/mainloop wakeup mechanism. The important
* point is that it actually does *NOTHING*.
*/
}
--- cut ---
Re: devuan
Max Nikulin wrote: > On 26/09/2023 14:19, Andrey Jr. Melnikov wrote: > > Max Nikulin wrote: > > > >> https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELS > >> я перестал понимать, куда его дальше-то расширять? Вроде наоборот хотят > >> сузить, выкинув /etc/powerstatus, по которому определяется, какой из 3 > >> скриптов запускать по SIGPWR > > Даа, читал ты его явно по диагонали. > Тем не менее единственное новое, что я увидел в пересказе, - это > /var/run/powerstatus, что не особенно принципиально (из разряда мелочь, > но приятно). > >>> L(OW) > >>> The power is failing and the UPS has a low battery. Execute the > >>> powerfailnow entries. > >> Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей > >> точки зрения, не лучше. > > Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся эта > > пляска вокруг файликов с сигналами и FIFO? > Я думаю, мы ни до чего не договоримся, да и не важно, ведь ни на что это > не повлияет. А чего тогда разговаривать... > Да, у меня прямо противоположное мнение о том, какой интерфейс лучше > подходит. Перенумеровать все возможные события - затея гиблая, люди в > них начнут путаться. Надо ведь еще и имена им дать. Поэтому я против 3-х > сигналов. > Я думаю, что когда люди выбрали один SIGPWR + /etc/powerstatus, они > рассматривали 3 сигнала и остановились на варианте, который сейчас > выглядит несколько вычурным. Когда они его выбирали - про SIGRTMIN ещё даже никто и не думал. SIGRTMIN появится только в POSIX 1003.1b а это 1993 год. Собственно по этому там такой изощрённый мультиплексор с файликом - сигнал один, а передать состоняие надо больше чем одно. > Послать-то сигнал может и просто, а вот правильно поймать уже некоторое > искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я > сигналы не люблю. Вот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы - хорошее, правильное асинхронное средство донести до процесса необходимую информацию. > С сокетами проще. Если есть утилита и библиотека, которые могут слать > нужные сообщения, и процесс их может правильно обработать, то это лучше, > чем сигналы. Мне такой вариант нравится больше. Проще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать ошибки, прочитать сокет (если прочитается), закрыть сокет.. и это все вместо одного signal handler? Нее, всё, больше с тобой разговривать не о чем, если ты совершенно не понимаешь условия задачи. Ты можешь во все запускаемые скрипты добавлять опрос ups - если тебе так удобно. Но мне - удобнее иметь три отдельных сигнала, три отдельных точки запуска - в которых в зависиомости от типа UPS будут или не будут отключатся сетевы интерфесы, система будет уходить в suspend-to-disk или полный power-off.
Re: devuan
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
coredumpsizeunlimited
Перезапускаем (/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 ?Ssl0:00 /usr/sbin/rsyslogd
Кстати, с тех пор как я писал сюда об "успешных" экспериментах по запуску
rsyslogd, тот опять обновился, и нынче его версия 8.2308.0-1, для i386.
--
Eugene Berdnikov
Re: devuan
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. А в консоль он что-нибудь пишет, когда не может запуститься? Останавливается перед этим нормально? В чём была проблема -- мне тогда докопаться не удалось (уже не помню, почему, кажется, под strace эта зараза всегда успешно работала, а без strace процесс исчезал, не оставляя ни корки, ни других следов). Либо не крэш, либо не может запись core файла подавлена. Как минимум 2 места есть: rlimits и sysctl kernel.core*, описано в core(5).
