devuan

[sergio]

В букворме сломана поддержка rsyslog в sysv:

1. удалён /etc/init.d/rsyslog
2. /usr/lib/rsyslog/rsyslog-rotate обрезан else про invoke-rc.d:

if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
else
invoke-rc.d rsyslog rotate > /dev/null
fi

Воспринимается это как целенаправленное вредительство и унижение
пользователей sysV. Можно, конечно, и то и то через /etc исправить (на
rsyslog-rotate ссылается /etc/logrotate.d/rsyslog), то есть update оно
переживать будет. А можно и по сторонам посмотреть. Есть у кого чего
сказать про devuan?


--
sergio.

[Eugene Berdnikov]

Не знаю про devuan, скажу про debian, ибо он эхотаг (привет фидошникам).

Rsyslog переломан в нескольких местах. При рестарте он запускается 50/50
(как те фашистские гранаты из культового боевика "Брат-2"). Почему так --
не знаю, и копать не хочется: судя по тому, что авторы rsyslog'а изобрели
в плане синтаксиса конфигов, в головах у них венигрет... Страшно подумать,
какой ужас там в коде, потому и лезть туда не хочется. Systemd его стартует
лишь потому, что расчитан на запуск даже таких калек, которые сами
с первой попытки подняться не могут.

Что там в голове у мантейнеров -- неведомо. Maybe это юные наруралисты,
которые SysV-init не видели и не догадываются, что его тоже нужно включить
в пакет... А может они в курсе, какое дерьмо мантейнят и просто забили
на SysV-init, поскольку заставить это нормально работать не удаётся.
Во всяком случае, мне не удалось. Пришлось делать крон-скрипт, который
проверяет наличие процесса rsyslogd и при отсутствии пытается запустить.
Так оно хоть как-то живёт на старых системах с SysV-init.

Единственная известная мне альтернатива rsyslog-у, умеющая делить логи
по шаблонам/регуляркам, это syslog-ng. К сожалению, сейчас его автора,
что называется, понесло... А раньше syslog-ng иногда подвисал из-за
какой-то баги. При этом он переставал принимать пакеты, и подвисала
практически вся система, ибо в юниксах код syslog(3) традиционно
блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все
материалы для багрепорта, но времени оформить его не хватило, пришлось
просто оставить syslog-ng. Альтернатива в виде rsyslog'а хоть с костылями
и через пень-колоду, но всё-таки работает и не убивает всю систему.
--
Eugene Berdnikov

[Alexey Shaposhnikov]

On Thu, 7 Sep 2023 01:38:27 +0300
sergio <ser...@outerface.net> wrote:

> Есть у кого чего сказать про devuan?

Ну, у меня он на домашней машине стоит (там микс из девуановских репозиториев
и deb-multimedia). Работает нормально, но, апстрим может погдадить. Так,
например, недавно libgudev поломало совместимость с eudev (подробности:
https://github.com/eudev-project/eudev/issues/249).

[Andrey Jr. Melnikov]

sergio <ser...@outerface.net> wrote:
> В букворме сломана поддержка rsyslog в sysv:

> 1. удалён /etc/init.d/rsyslog
> 2. /usr/lib/rsyslog/rsyslog-rotate обрезан else про invoke-rc.d:

> if [ -d /run/systemd/system ]; then
> systemctl kill -s HUP rsyslog.service
> else
> invoke-rc.d rsyslog rotate > /dev/null
> fi

> Воспринимается это как целенаправленное вредительство и унижение
> пользователей sysV. Можно, конечно, и то и то через /etc исправить (на

Да, у них политика партии - systemd. И эта политика получается из-за gnome и
лени маинтайнеров поддерживать всё остальное.
Я себе держу приватный репозиорий, в котором собираю необходимые пакеты сам,
с нужными скриптами/патчами/etc.

> rsyslog-rotate ссылается /etc/logrotate.d/rsyslog), то есть update оно
> переживать будет.

Зачем всё так сложно ? Поставь orphan-sysvinit-scripts - оно само тебе
файлики как надо поменяет.

> А можно и по сторонам посмотреть. Есть у кого чего сказать про devuan?

Эти тоже со своими тараканами. Почему нельзя было взять udev из дебиана и
его использовать? Нет, надо тащить eudev в который запиливать фичи из udev.
Классическое "К соседу в сарай через Никарагуа".

[Tim Sattarov]

On 2023-09-07 04:09, Eugene Berdnikov wrote:

 Rsyslog переломан в нескольких местах. 

Если не ошибаюсь, то в последнем (12) Дебьяне rsyslog по умолчанию не ставится и стоит только системный журнал из systemd...

https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm

[Alexander Gerasiov]

On Thu, 7 Sep 2023 14:11:06 +0300
"Andrey Jr. Melnikov" <temno...@gmail.com> wrote:

> > А можно и по сторонам посмотреть. Есть у кого чего сказать про
> > devuan?
> Эти тоже со своими тараканами. Почему нельзя было взять udev из
> дебиана и его использовать? Нет, надо тащить eudev в который
> запиливать фичи из udev. Классическое "К соседу в сарай через
> Никарагуа".

Так нынешний udev - это кусок systemd. Его, конечно, можно без самого
systemd использовать, но ненависть к systemd - это скорее религиозное,
так что udev из него брать тоже нельзя ни в коем случае.


--
Best regards,
Alexander Gerasiov

Contacts:
e-mail: a...@gerasiov.net WWW: https://gerasiov.net TG/Skype: gerasiov
PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1

[Max Nikulin]

Тогда уж
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#changes-to-system-logging

Я за развитием сюжета не следил, но есть ощущение, что просто люди
жаловались, что место на диске тратится на второй экземпляр логов,
которые можно достать из journald. Я не буду спорить, что в некоторых
случаях rsyslog может не работать. При этом я удивлюсь, если услышу
убедительные аргументы против того, что он нормально работал почти у всех.

А по поводу rsyslog-rotate, можно проверить, что патч
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031399#24
накладывается и корректно работает, а потом вежливо, без негатива в
сторону systemd/journald, о нем напомнить, подтвердив, что он решает
проблему.

В unstable вроде версия обновилась несколько раз, так что пакет не
выглядит заброшенным. Сомневаюсь правда, что исправление попадет в
bookworm, если не случится какой-нибудь страшный CVE. Может в devuan
пересоберут пакет.

P.S. Можно еще в скрипт добавить дополнительный else с вызовом logger,
чтобы напомнить администратору, что ротацию логов надо чинить.

[Eugene Berdnikov]

On Sat, Sep 09, 2023 at 09:41:36AM +0700, Max Nikulin wrote:
> А по поводу rsyslog-rotate, можно проверить, что патч
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031399#24 накладывается и

> корректно работает, а потом вежливо, [...]

Этот патч требует /etc/init.d/rsyslog, что, собственно, в комментарии
к нему и написано. А скрипт этот в дистрибутив не положили.

Но там не написано, что выполнить задачу скрипта /etc/init.d/rsyslog
не очень просто, потому что rsyslogd при рестарте запускается через раз.
Мои попытки сделать в скрипте цикл и на каждой итерации проверять,
запустился rsyslogd или нет, не привели к успеху даже в варианте
"5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали
случаи, когда процесс не запускался. Автоподъём по крону эту проблему
решает, но нужно понимать, что иногда система живёт без сислога.
--
Eugene Berdnikov

[Max Nikulin]

On 10/09/2023 03:58, Eugene Berdnikov wrote:
> On Sat, Sep 09, 2023 at 09:41:36AM +0700, Max Nikulin wrote:
>> А по поводу rsyslog-rotate, можно проверить, что патч
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031399#24 накладывается и
>> корректно работает, а потом вежливо, [...]
>
> Этот патч требует /etc/init.d/rsyslog, что, собственно, в комментарии
> к нему и написано. А скрипт этот в дистрибутив не положили.

Вот для тех, кто забудет про init скрипт, я и предлагал добавить logger.

Andrey Jr. Melnikov уже написал, что скрипт положили, но в пакет
orphan-sysvinit-scripts. Правда туда положили и
/usr/lib/rsyslog/rsyslog-rotate.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031854
orphan-sysvinit-scripts: should cope with defective rsyslog-rotate

Глядя со стороны, кажется, что все должно работать.

> Но там не написано, что выполнить задачу скрипта /etc/init.d/rsyslog
> не очень просто, потому что rsyslogd при рестарте запускается через раз.
> Мои попытки сделать в скрипте цикл и на каждой итерации проверять,
> запустился rsyslogd или нет, не привели к успеху даже в варианте
> "5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали
> случаи, когда процесс не запускался. Автоподъём по крону эту проблему
> решает, но нужно понимать, что иногда система живёт без сислога.

А оригинальный init скрипт с этой задачей не справлялся что-ли? Какие-то
сложности с сетевыми сокетами или что-то другое?

[Andrey Lu]

07.09.2023 15:09, Eugene Berdnikov пишет:

> Единственная известная мне альтернатива rsyslog-у, умеющая делить логи
> по шаблонам/регуляркам, это syslog-ng. К сожалению, сейчас его автора,
> что называется, понесло... А раньше syslog-ng иногда подвисал из-за
> какой-то баги. При этом он переставал принимать пакеты, и подвисала
> практически вся система, ибо в юниксах код syslog(3) традиционно
> блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все
> материалы для багрепорта, но времени оформить его не хватило, пришлось
> просто оставить syslog-ng. Альтернатива в виде rsyslog'а хоть с костылями
> и через пень-колоду, но всё-таки работает и не убивает всю систему.

Можно поподробнее про syslog-ng ? используем syslog-ng на большом
количестве серверов со стретча до булзая, в разных позах - никаких
проблем не замечали

[Eugene Berdnikov]

On Tue, Sep 12, 2023 at 05:40:36PM +0700, Andrey Lu wrote:
> 07.09.2023 15:09, Eugene Berdnikov пишет:

[...]

> > что называется, понесло... А раньше syslog-ng иногда подвисал из-за
> > какой-то баги. При этом он переставал принимать пакеты, и подвисала
> > практически вся система, ибо в юниксах код syslog(3) традиционно
> > блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все
> > материалы для багрепорта, но времени оформить его не хватило, пришлось

[...]

> Можно поподробнее про syslog-ng ? используем syslog-ng на большом количестве
> серверов со стретча до булзая, в разных позах - никаких проблем не замечали

Нашёл файлики от июля 2019, созданные когда я готовил багрепорт.
В них видно, что syslog-ng стопорится на операции записи

send(32, "<39>Jul 20 07:49:29 syslog-ng: DIGEST-MD5 common mech free", 58, MSG_NOSIGNAL

a lsof в этот замечательный момент показывает

COMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME
syslog-ng 18274 root 32u unix 0x00000000c94137a7 0t0 5922798 type=DGRAM

Т.е. syslog-ng пытается писать в сокет, клонированный accept()ом
от /dev/log. Но с обратной стороны никто не собирается читать, там
сидит чукча-писатель с syslog(3). А поскольку send() с MSG_NOSIGNAL,
и, ясный пень, без таймера, то наступает капец. Ни по ssh зайти
на эту машину, ни с консоли, поскольку и sshd, и getty->login вызывают
синхронный syslog(3), на котором точно так же виснут.

Бага проявлялась редко, но на физических хостах она отличалась особой
неприятностью. И неуловимостью. А в контейнере поймалась на ура.
Возможно, это уже починили, всё-таки 4 года прошло.
--
Eugene Berdnikov

[Eugene Berdnikov]

On Sun, Sep 10, 2023 at 11:02:39PM +0700, Max Nikulin wrote:
> Andrey Jr. Melnikov уже написал, что скрипт положили, но в пакет
> orphan-sysvinit-scripts. Правда туда положили и
> /usr/lib/rsyslog/rsyslog-rotate.

[...]

> > Но там не написано, что выполнить задачу скрипта /etc/init.d/rsyslog
> > не очень просто, потому что rsyslogd при рестарте запускается через раз.
> > Мои попытки сделать в скрипте цикл и на каждой итерации проверять,
> > запустился rsyslogd или нет, не привели к успеху даже в варианте
> > "5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали
> > случаи, когда процесс не запускался. Автоподъём по крону эту проблему
> > решает, но нужно понимать, что иногда система живёт без сислога.
>
> А оригинальный init скрипт с этой задачей не справлялся что-ли? Какие-то
> сложности с сетевыми сокетами или что-то другое?

Вытащил скрипт из свежего orphan-sysvinit-scripts, о котором я не знал.
Там скрипт совсем свеженький, датирован 3 сентября 2023. При сравнении
с моим собственным скриптом (последняя правка от 30-янв-2022) нашлось
лишь одно отличие: у меня start-stop-daemon вызывается с опцией -oknodo,
в остальном скрипты по сути совпадают. И выяснилось, что сейчас оба
успешно перезапускают rsyslogd... :) В чём была проблема -- мне тогда
докопаться не удалось (уже не помню, почему, кажется, под strace эта
зараза всегда успешно работала, а без strace процесс исчезал, не оставляя
ни корки, ни других следов). Возможно, багу пофиксили, поскольку ryslog
с тех пор обновлялся, в том числе совсем недавно:

2023-08-19 21:42:26 upgrade rsyslog:i386 8.2306.0-2 8.2308.0-1
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Sun, Sep 10, 2023 at 11:02:39PM +0700, Max Nikulin wrote:
> > Andrey Jr. Melnikov уже написал, что скрипт положили, но в пакет
> > orphan-sysvinit-scripts. Правда туда положили и
> > /usr/lib/rsyslog/rsyslog-rotate.

[...]

> Вытащил скрипт из свежего orphan-sysvinit-scripts, о котором я не знал.
> Там скрипт совсем свеженький, датирован 3 сентября 2023. При сравнении
> с моим собственным скриптом (последняя правка от 30-янв-2022) нашлось
> лишь одно отличие: у меня start-stop-daemon вызывается с опцией -oknodo,
> в остальном скрипты по сути совпадают. И выяснилось, что сейчас оба
> успешно перезапускают rsyslogd... :) В чём была проблема -- мне тогда
> докопаться не удалось (уже не помню, почему, кажется, под strace эта
> зараза всегда успешно работала, а без strace процесс исчезал, не оставляя
> ни корки, ни других следов). Возможно, багу пофиксили, поскольку ryslog
> с тех пор обновлялся, в том числе совсем недавно:

А у тебя случаем контейнеров на машинке не крутится? А то смотри,
start-stop-daemon у нас тупенький, он про отдельные неймспесы ничего не
знает. Поэтому, когда у тебя запущенно несколько экземпляров чего либо в
различных контейнерах - start-stop-daemon на host-машине ведет себя весма
оригинально - то сигнал не в тот процесс пришлёт, то узрит живущий демон в
контенйнере и откажется запускать его-же на хосте. Из-за этого, приходтся
весь пакадж с dpkg пересобирать. Хотя, надо наверное сделать отдельный и
через dpkg-divert подсовывать нужный start-stop-daemon.

[Eugene Berdnikov]

On Thu, Sep 14, 2023 at 12:21:03PM +0300, Andrey Jr. Melnikov wrote:
> А у тебя случаем контейнеров на машинке не крутится? А то смотри,
> start-stop-daemon у нас тупенький, он про отдельные неймспесы ничего не
> знает. Поэтому, когда у тебя запущенно несколько экземпляров чего либо в
> различных контейнерах - start-stop-daemon на host-машине ведет себя весма
> оригинально - то сигнал не в тот процесс пришлёт, то узрит живущий демон в
> контенйнере и откажется запускать его-же на хосте. Из-за этого, приходтся
> весь пакадж с dpkg пересобирать. Хотя, надо наверное сделать отдельный и
> через dpkg-divert подсовывать нужный start-stop-daemon.

У меня везде, где есть контейнеры, стоит система инициализации systemd.
Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно
запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный
бег по граблям).

Но я писал про сислоги в контексте физических машин и контейнеров
без вложенности, где start-stop-daemon ошибиться не может.
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Thu, Sep 14, 2023 at 12:21:03PM +0300, Andrey Jr. Melnikov wrote:
> > А у тебя случаем контейнеров на машинке не крутится? А то смотри,
> > start-stop-daemon у нас тупенький, он про отдельные неймспесы ничего не
> > знает. Поэтому, когда у тебя запущенно несколько экземпляров чего либо в
> > различных контейнерах - start-stop-daemon на host-машине ведет себя весма
> > оригинально - то сигнал не в тот процесс пришлёт, то узрит живущий демон в
> > контенйнере и откажется запускать его-же на хосте. Из-за этого, приходтся
> > весь пакадж с dpkg пересобирать. Хотя, надо наверное сделать отдельный и
> > через dpkg-divert подсовывать нужный start-stop-daemon.

> У меня везде, где есть контейнеры, стоит система инициализации systemd.
> Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно
> запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный
> бег по граблям).

У меня везде стоит SysV-init где контейнеры. И ничего - граблей не наблюдаю.
И даже контейненры с systemd внутри - тоже работают, хотя раньше это изделие
не могло там стартануть нормально.

> Но я писал про сислоги в контексте физических машин и контейнеров
> без вложенности, где start-stop-daemon ошибиться не может.

Вопрос не во вложенности, а имеено в том, что на физическом хосте
start-stop-daemon путается в запущенном. Следи за руками:

~# ps ax | grep cron
1722 ? Ss 0:00 /usr/sbin/cron -f
23546 ? Ss 0:00 /usr/sbin/cron
23772 pts/0 S+ 0:00 grep cron
~# start-stop-daemon --status --exec /usr/sbin/cron ; echo $?

0
~# /etc/init.d/cron stop
Stopping cron (via systemctl): cron.service.
~# ps ax | grep cron
23546 ? Ss 0:00 /usr/sbin/cron
23798 pts/0 S+ 0:00 grep cron
~# start-stop-daemon --status --exec /usr/sbin/cron ; echo $?

0

Видишь, на хосте cron не работает, в контейнере - работет, но по мнению
start-stop-daemon - он работает на хосте.

Остановим контейнер:

~# lxc-stop test
~# ps ax | grep cron
24127 pts/0 S+ 0:00 grep cron
~# start-stop-daemon --status --exec /usr/sbin/cron ; echo $?
3

О. Теперь мы заметили, что "program is not running". Вот такая чудная
запускалка демонов.

[Eugene Berdnikov]

On Thu, Sep 14, 2023 at 02:26:07PM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <b...@protva.ru> wrote:
> > У меня везде, где есть контейнеры, стоит система инициализации systemd.
> > Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно
> > запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный
> > бег по граблям).
> У меня везде стоит SysV-init где контейнеры. И ничего - граблей не наблюдаю.
> И даже контейненры с systemd внутри - тоже работают, хотя раньше это изделие
> не могло там стартануть нормально.

Ну так 1. я про то, что было раньше, несколько лет назад, 2. контейнеры
они разные бывают. Несколько лет назад я пытался завести lxc-шные,
начитался разных wiki на тему "как заставить это работать под SysV",
и в итоге сделал для себя вывод, что проще поставить на хост systemd
чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально
отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало,
что под SysV лечилось лишь напильником.

Тенденция такова, что как только отстал от мейстрима, так проблемы растут,
отнимая всё больше времени и сил... Вон, формально для i686 до сих пор
собирают mplayer и chrome. Однако на тех процах, которые были во времена
мейнстрима i686, как правило, не было SSSE3, которые эти изделия хотят.
И ведь можно было бы обойтись, просто работать медленнее, но нет, кодерам
неинтересна поддержка "убогих" процов, им проще тупо вернуть статус-код.
Ну а если у меня современный проц, зачем мне гонять на нём 32-битную
базовую систему? Я 64 заведу, а всякие ископаемые конфигурации, которые
слишком дорого переделывать, загоню в 32-битные виртуалки/контейнеры.

И так оно везде, к сожалению. В том числе в виртуализации, всех видов.

> Вопрос не во вложенности, а имеено в том, что на физическом хосте
> start-stop-daemon путается в запущенном. Следи за руками:

Да это понятно. Я про то, что в контейнере start-stop-daemon не путается,
если там других (вложенных) контейнеров нет. Потому как в контейнере
ему лишь свои и дочерние процессы видны. Поэтому под systemd контейнер
с инициализаций SysV нормально живёт.
--
Eugene Berdnikov

[dimas]

pid-файл? не, не слышали
grep "pid" /etc/init.d/cron
PIDFILE=/var/run/crond.pid
start_daemon -p $PIDFILE $DAEMON $EXTRA_OPTS
killproc -p $PIDFILE $DAEMON
[ $RETVAL -eq 0 ] && [ -e "$PIDFILE" ] && rm -f $PIDFILE
status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
почему оно должно путаться - я вообще не понимаю

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Thu, Sep 14, 2023 at 02:26:07PM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <b...@protva.ru> wrote:
> > > У меня везде, где есть контейнеры, стоит система инициализации systemd.
> > > Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно
> > > запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный
> > > бег по граблям).
> > У меня везде стоит SysV-init где контейнеры. И ничего - граблей не наблюдаю.
> > И даже контейненры с systemd внутри - тоже работают, хотя раньше это изделие
> > не могло там стартануть нормально.

> Ну так 1. я про то, что было раньше, несколько лет назад, 2. контейнеры
> они разные бывают. Несколько лет назад я пытался завести lxc-шные,
> начитался разных wiki на тему "как заставить это работать под SysV",
> и в итоге сделал для себя вывод, что проще поставить на хост systemd
> чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально
> отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало,
> что под SysV лечилось лишь напильником.

Хахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело
в том, что lxc использует SIGPWR для останова контенйнеров, а в inittab'e от
SysV-init прописано обработчик "pf::powerwait:/etc/init.d/powerfail start"
который ещё 10 лет назад был в пакетах powstatd/genpower и которые выкинули
из unstable где-то в районе squeeze/wheezy. А про скриптик - так и забыли,
сейчас не модно держать UPS подключенный к машине.

> Тенденция такова, что как только отстал от мейстрима, так проблемы растут,
> отнимая всё больше времени и сил... Вон, формально для i686 до сих пор
> собирают mplayer и chrome. Однако на тех процах, которые были во времена

Эмм, за последние 15 лет не выпускалось процессоров без поддержки x64.
Системы 10и летней давности - ужасно энерго неэффективны, их проще менять
целиком на что-то более новоее. Вон китайский плеер за 2 тысячи рублей -
вполне помещается за телевизором, крутит HD видео без заиканий и потери
кадров и при этом - не шумит и не греет воздух.

> мейнстрима i686, как правило, не было SSSE3, которые эти изделия хотят.
> И ведь можно было бы обойтись, просто работать медленнее, но нет, кодерам
> неинтересна поддержка "убогих" процов, им проще тупо вернуть статус-код.

SSE3, как впрочем и всякие AVX512 - сильно перероценён и больше представляет
из себя маркетинговый буллщит в стиле "а у нас страшных буковок больше".

> Ну а если у меня современный проц, зачем мне гонять на нём 32-битную
> базовую систему? Я 64 заведу, а всякие ископаемые конфигурации, которые
> слишком дорого переделывать, загоню в 32-битные виртуалки/контейнеры.

Закапывать надо такие конфигурации, как стюардессу.

> И так оно везде, к сожалению. В том числе в виртуализации, всех видов.

> > Вопрос не во вложенности, а имеено в том, что на физическом хосте
> > start-stop-daemon путается в запущенном. Следи за руками:

> Да это понятно. Я про то, что в контейнере start-stop-daemon не путается,
> если там других (вложенных) контейнеров нет. Потому как в контейнере
> ему лишь свои и дочерние процессы видны. Поэтому под systemd контейнер
> с инициализаций SysV нормально живёт.

Контенер с SysV живёт где угодно, ему тупо не надо, как systemd -
смонтированных cgroupv2 псевдо-fs для работы. А вот systemd - вынь да полож.

[Andrey Jr. Melnikov]

dimas <dima...@ya.ru> wrote:
> pid-файл? не, не слышали
Нет конечно, не слышали, откуда нам.

Во первых - это был пример. Во вторых - не каждый демон первым делом создаёт
pid файл, он может задуматься на ресолвинге имён или ещё каких своих
потребностях. И в обратную сторону так-же - демон останавливается, pid уже
стёр, а сам ещё не выгрузился. Поэтому - демон afrnbxtcrb запущен, а
pid-файла - нет.

[Eugene Berdnikov]

On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <b...@protva.ru> wrote:
> > и в итоге сделал для себя вывод, что проще поставить на хост systemd
> > чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально
> > отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало,
> > что под SysV лечилось лишь напильником.
> Хахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело
> в том, что lxc использует SIGPWR для останова контенйнеров, а в inittab'e от
> SysV-init прописано обработчик "pf::powerwait:/etc/init.d/powerfail start"

Если такая грабля существовала, это не то, с чем сталкивался я...
Насчёт SIGPWR не знаю, скорее всего он используется, но конечный результат
зависит и от процесса, управляющего контейнером, и от поведения init'а
внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года
(с апдейтами, да), с такими строчками в inittab'e:

# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

причём никаких /etc/init.d/power* нет, а системы нормально гасятся и
поднимаются. Под systemd. Когда я игрался с подобными контейнерами
под SysV, там было примерно такое: по lxc-stop контейнер шустро
сворачивается, а потом lxc-stop висит 2-3 минуты, ожидая какого-то
ответа из сокета, и выдаёт невразумительное сообщение об ошибке.
При этом в контейнере ничего не ломается.

И много подобных неудобств и граблей было, всех уже не вспомнить...

Если сегодня под SysV инфраструктура lxc нормально живёт, это замечательно,
но мне надо было вчера, и для этих задач я для себя выбрал systemd.
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <b...@protva.ru> wrote:
> > > и в итоге сделал для себя вывод, что проще поставить на хост systemd
> > > чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально
> > > отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало,
> > > что под SysV лечилось лишь напильником.
> > Хахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело
> > в том, что lxc использует SIGPWR для останова контенйнеров, а в inittab'e от
> > SysV-init прописано обработчик "pf::powerwait:/etc/init.d/powerfail start"

> Если такая грабля существовала, это не то, с чем сталкивался я...
> Насчёт SIGPWR не знаю, скорее всего он используется, но конечный результат
> зависит и от процесса, управляющего контейнером, и от поведения init'а
> внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года
> (с апдейтами, да), с такими строчками в inittab'e:

> # What to do when the power fails/returns.
> pf::powerwait:/etc/init.d/powerfail start
> pn::powerfailnow:/etc/init.d/powerfail now
> po::powerokwait:/etc/init.d/powerfail stop

> причём никаких /etc/init.d/power* нет, а системы нормально гасятся и
> поднимаются. Под systemd.

Так systemd плевать хотел на /etc/initttab. Он им не пользуется. И на SIGPWR
тоже, т.к. у Поттеринга на него алергия:

-- cut --
My recommendatin: don't bother with SIGPWR. Traditionally on UNIX UPS
software sends SIGPWR to PID 1 to initiate some special kind of
shutdown operation. But it's very vaguely defined only, and one
wonders why a normal shutdown isn't enough here, and why to bounce
this off PID 1 with a special UNIX signal even...

I am pretty sure that power management software that runs in userspace
really shouldn't make use of this anymore. It should just request a
normal shutdown. The only reason why one would want to bother with
SIGPWR at all is that some really power-related old kernel drivers
send SIGPWR to PID 1 too.

>From the systemd PoV: this stuff is ugly legacy crap that only exists
for historic reasons and was never really well-defined in its
behavour. It mostly appears to be a concept that exists only because
Linux never had a useful IPC that was accessible from both kernelspace
and userspace in a sane way... In systemd, we don't want anything to
do with it, but some legacy folks really think it's superduper
important. Hence we simply map it to a target unit, and enable users
to map it to whatever they want to map it, but don't do anything smart
about it at all on our own.

I think it would be best of people would just forget about it...

Lennart
-- cut --

так что, там используется SIGRTMIN+4, потмоу что вот.

> Когда я игрался с подобными контейнерами под SysV, там было примерно
> такое: по lxc-stop контейнер шустро сворачивается, а потом lxc-stop
> висит 2-3 минуты, ожидая какого-то ответа из сокета, и выдаёт
> невразумительное сообщение об ошибке. При этом в контейнере ничего
> не ломается.

Там было 2 проблемы - кривость в использовании io_uring, и ещё какие-то
проблемы с управляющим терминалом (точнее с детачингом от него демонов,
которые ну очень хотят в него отсылать сообщения).
Но меня эта проблема не волнует - контейнеры останавливаются редко, спешки в
этом никакой нет. А то, что надо прям сейчас - подхватит другой контейнер,
после того, как init убъет VRRP демона. А что он там будет делать дальше -
никого уже не волнует.

> И много подобных неудобств и граблей было, всех уже не вспомнить...
>
> Если сегодня под SysV инфраструктура lxc нормально живёт, это замечательно,
> но мне надо было вчера, и для этих задач я для себя выбрал systemd.

У меня и работает со вчера. Только пришлось немного посмотреть, почему оно
так. А верить в магию systemd "просто поставь его" - это не наш метод.

[Max Nikulin]

On 14/09/2023 18:26, Andrey Jr. Melnikov wrote:
> Вопрос не во вложенности, а имеено в том, что на физическом хосте
> start-stop-daemon путается в запущенном. Следи за руками:
>
> ~# ps ax | grep cron
> 1722 ? Ss 0:00 /usr/sbin/cron -f
> 23546 ? Ss 0:00 /usr/sbin/cron
> 23772 pts/0 S+ 0:00 grep cron

А научить его действительно проблема? Наугад попробовал

ps -eo pid,pidns,user,cmd f

контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc
вроде создает, так что это влиять не должно.

[Eugene Berdnikov]

On Fri, Sep 15, 2023 at 05:03:50PM +0300, Andrey Jr. Melnikov wrote:
> Eugene Berdnikov <b...@protva.ru> wrote:
> > внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года
> > (с апдейтами, да), с такими строчками в inittab'e:
>
> > # What to do when the power fails/returns.
> > pf::powerwait:/etc/init.d/powerfail start
> > pn::powerfailnow:/etc/init.d/powerfail now
> > po::powerokwait:/etc/init.d/powerfail stop
>
> > причём никаких /etc/init.d/power* нет, а системы нормально гасятся и
> > поднимаются. Под systemd.
> Так systemd плевать хотел на /etc/initttab. Он им не пользуется.

В верхней строчке написано: "дебианы от 2008 года". Ясное дело, там SysV,
в контейнере, а не снаружи. Ты бы хоть читал то, на что отвечаешь...

> И на SIGPWR тоже, т.к. у Поттеринга на него алергия:

Согласен с Поттерингом: да, все варианты проблем с электропитанием в один
лишь SIGPWR запихнуть невозможно, потому и сакрального смысла в нём нет.

Трахаться с ним или сразу закопать -- решать Поттерингу: он свои силы
тратит на движение прогресса, а мы пользуемся результатом.
--
Eugene Berdnikov

[Eugene Berdnikov]

On Tue, Sep 19, 2023 at 10:02:00AM +0300, Andrey Jr. Melnikov wrote:
> Max Nikulin <mani...@gmail.com> wrote:
> > контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc
> > вроде создает, так что это влиять не должно.
>

> Нет, не проблема. Проблема написать баг-репорт и донести его нужность до
> маинтайнеров, у которых теперь есть на всё одна отмазка "sysvinit устарел,
> под systemd всё работает (C)".

Писать лучше патч, с ним багрепорт имеет намного больше шансов на успех.
Хотя и это не всегда помогает...
--
Eugene Berdnikov

[Andrey Jr. Melnikov]

Eugene Berdnikov <b...@protva.ru> wrote:
> On Fri, Sep 15, 2023 at 05:03:50PM +0300, Andrey Jr. Melnikov wrote:
> > Eugene Berdnikov <b...@protva.ru> wrote:
> > > внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года
> > > (с апдейтами, да), с такими строчками в inittab'e:
> >
> > > # What to do when the power fails/returns.
> > > pf::powerwait:/etc/init.d/powerfail start
> > > pn::powerfailnow:/etc/init.d/powerfail now
> > > po::powerokwait:/etc/init.d/powerfail stop
> >
> > > причём никаких /etc/init.d/power* нет, а системы нормально гасятся и
> > > поднимаются. Под systemd.
> > Так systemd плевать хотел на /etc/initttab. Он им не пользуется.
> В верхней строчке написано: "дебианы от 2008 года". Ясное дело, там SysV,
> в контейнере, а не снаружи. Ты бы хоть читал то, на что отвечаешь...

Я говорил про lxc и его поведение. То, что у тебя контейнеры тупили при
остановке в 60 секунд - это оно и есть - сначала посылается SIGPWR, на
который нет реакци, ждётся 60 секунд и посылается SKIGKILL всему, что там
запущенно.

> > И на SIGPWR тоже, т.к. у Поттеринга на него алергия:

> Согласен с Поттерингом: да, все варианты проблем с электропитанием в один
> лишь SIGPWR запихнуть невозможно, потому и сакрального смысла в нём нет.
>
> Трахаться с ним или сразу закопать -- решать Поттерингу: он свои силы
> тратит на движение прогресса, а мы пользуемся результатом.

Увы, Лёня ещё тот чудак на другую букву. И ничего нового (кроме сказок о том
как всё устарело) он и не сделал. Поэтому, SIGPWR как был - так и остался. И
вместо скриптика - вызывает sigpwr.target. Я бы понял, если бы он сделал 3
сигнала SIGPWR для информирования о том, что питание пропало, SIGRTMIN+x1
для информирования о том, что питание появилось обратно и SIGRTMIN+x2 - для
emergency power shutdown - был бы разговор о прогрессе и удобстве.
А так - вот вам SIGPWR и всё дальше сами угадывайте. Да, задизайнить
SIGRTMIN+4 в poweroff и SIGRTMIN+14 в immediate poweroff - смог, но это
деление ничего не даёт в случае с пропаданием питания. Ни-че-го. Только
скриптик вызывающий "shutdown -h 0" заменили на sigpwr.target. Иннновации, ё!

[Andrey Jr. Melnikov]

[Max Nikulin]

Я бы еще добавил, что договариваться надо скорее с разработчиками,
которые сейчас поддерживают start-stop-daemon, чем с сопровождающими пакет.

Странное ощущение возникло от этого обсуждения. Участники вдоволь
оттоптались на граблях, представляют, в каком месте надо чинить, вроде
есть возможность проверить, что исправленная версия будет правильно
работать, но заниматься этим должен кто-то другой, у кого, возможно,
времени хватает только на то, чтобы следить, что под systemd работает.

P.S. А если демон намеренно решил самоизолироваться в своем pidns? Не
сравняется ли в результате SysV init по развесистости с systemd, если
учесть все эти нюансы?

[Max Nikulin]

On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
> Я бы понял, если бы он сделал 3
> сигнала SIGPWR для информирования о том, что питание пропало, SIGRTMIN+x1
> для информирования о том, что питание появилось обратно и SIGRTMIN+x2 - для
> emergency power shutdown - был бы разговор о прогрессе и удобстве.

Лично у меня сомнения, что этим должен заниматься именно init. Вроде
задача для пользовательского процесса, который сходит спросит, сколько
заряда осталось у аккумулятора, а потом уже будет решать, на сколько
спешно надо останавливать систему. В ноутбуках акселерометры, по которым
можно парковать головки жесткого диска при падении, доступны просто как
файлы в /sys. Реакция на событие нужна за доли секунды, а init для этого
не обязателен.

Не убедительно, что сообщать о пропадании/восстановлении питания надо
именно разными сигналами.

[Andrey Jr. Melnikov]

Max Nikulin <mani...@gmail.com> wrote:
> On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
> > Я бы понял, если бы он сделал 3
> > сигнала SIGPWR для информирования о том, что питание пропало, SIGRTMIN+x1
> > для информирования о том, что питание появилось обратно и SIGRTMIN+x2 - для
> > emergency power shutdown - был бы разговор о прогрессе и удобстве.

> Лично у меня сомнения, что этим должен заниматься именно init.

init должен запускать просто нужный target/script/runlevel/чётамещё.

> Вроде задача для пользовательского процесса, который сходит спросит, сколько
> заряда осталось у аккумулятора, а потом уже будет решать, на сколько
> спешно надо останавливать систему. В ноутбуках акселерометры, по которым
> можно парковать головки жесткого диска при падении, доступны просто как
> файлы в /sys.

Диск сам запаркуется. Он тупо ближе к акселерометру и быстрее.

> Реакция на событие нужна за доли секунды, а init для этого не обязателен.

Он для этого и не нужен. init и обработка realtime сигналов - это из области
фантастики. особенно с systemd который обязательно захочет послать сигнал
через dbus текущей парковалке головок диска.

> Не убедительно, что сообщать о пропадании/восстановлении питания надо
> именно разными сигналами.

Для ноутбука - может и не убедительно, а для удалённого UPS, который где-то
там по сети висит и по SNMP мониториться - ещё как убедительно.

Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало
питание - посылает сигнал, появилось - посылает сигнал (ну тут всё
стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть
понимание - init дернул power-loss скриптик, в котором уже можно оценить
масштаб проблемы, остановить нужное и принять решение - ждём восстановления
или отключаемся. Или init дернул power-restored - когда поднимаем
остановленное или в зависимости от - тупо перезагружаемся.
Нет, через один SIGPWR это тоже всё решалось и решается, только вот скриптик
будет разляпистее.

[Max Nikulin]

On 24/09/2023 01:52, Andrey Jr. Melnikov wrote:
> Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало
> питание - посылает сигнал, появилось - посылает сигнал (ну тут всё
> стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть
> понимание - init дернул power-loss скриптик, в котором уже можно оценить
> масштаб проблемы, остановить нужное и принять решение - ждём восстановления
> или отключаемся. Или init дернул power-restored - когда поднимаем
> остановленное или в зависимости от - тупо перезагружаемся.
> Нет, через один SIGPWR это тоже всё решалось и решается, только вот скриптик
> будет разляпистее.

Я все еще сомневаюсь, нужно ли здесь завязываться на init.

Почему обычный демон не может сам запускать, в зависимости от ситуации,
либо power-loss, либо power-restored скрипты? В чем польза того, что в
промежутке между ними init и сигналы?

Единственное преимущество от SIGPWR, которое я вижу, - это
зафиксированный API. Недостаток - API очень ограниченный. Даже если
добавить еще сигналов, то становится не очевидно, какому сигналу
соответствует событие. /etc/inittab как известная точка конфигурации для
меня не убедительное достоинство, не SysV init может использовать другой
файл, чтобы назначать обработчики.

Если скрипты запускаются напрямую демоном, который слушает SNMP, то
событий может быть несколько и со вполне нормальными именами. Главная
проблема - договориться о именах скриптов и их параметрах. Иначе будет
головная боль с тем, что у каждого производителя UPS они будут свои и не
очень совместимые между собой. Да, договариваться сложно, уходящий
корнями в прошлое SIGPWR, выглядит более знакомым и поэтому привлекательным.

[Михаил Касаджиков]

Для того чтобы демон ИБП мог потушить весь сервер ему нужны соответствующие права, а он может быть запущен с понижением привилегий. И послать сигнал SIGPWR иниту он может, а вот уже запустить /sbin/shutdown — рожей не вышел.

В воскресенье 24 сентябрь 2023 10:58:55 (+03:00), Max Nikulin пишет:

[Andrey Jr. Melnikov]

Max Nikulin <mani...@gmail.com> wrote:
> On 24/09/2023 01:52, Andrey Jr. Melnikov wrote:
> > Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало
> > питание - посылает сигнал, появилось - посылает сигнал (ну тут всё
> > стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть
> > понимание - init дернул power-loss скриптик, в котором уже можно оценить
> > масштаб проблемы, остановить нужное и принять решение - ждём восстановления
> > или отключаемся. Или init дернул power-restored - когда поднимаем
> > остановленное или в зависимости от - тупо перезагружаемся.
> > Нет, через один SIGPWR это тоже всё решалось и решается, только вот скриптик
> > будет разляпистее.

> Я все еще сомневаюсь, нужно ли здесь завязываться на init.

> Почему обычный демон не может сам запускать, в зависимости от ситуации,
> либо power-loss, либо power-restored скрипты? В чем польза того, что в
> промежутке между ними init и сигналы?

Поздравляю, ты придумал init в софтине для UPS. Теперь все остальные должны
знать про неё - а она должна знать про всё остальное.

> Единственное преимущество от SIGPWR, которое я вижу, - это

Приемущество - то, что интерфейс сискола signal(..) известен всем и каждому,
сигнал можно отослать без знания, что там у нас за init и в какой сокет ему
надо что нашептать (и пустят ли туда этого демона).

> зафиксированный API. Недостаток - API очень ограниченный.

Недостаток тут только один - невозможно выборочно остановить/запустить
демоны, которые жрут электричество/обрабатывают данные.. Лишний target эту
проблему слегка облегчает.

> Даже если добавить еще сигналов, то становится не очевидно, какому сигналу
> соответствует событие. /etc/inittab как известная точка конфигурации для

т.е. прочитать в man'e про конфигурацию используемого init'a - это не модно?

> меня не убедительное достоинство, не SysV init может использовать другой
> файл, чтобы назначать обработчики.

> Если скрипты запускаются напрямую демоном, который слушает SNMP, то
> событий может быть несколько и со вполне нормальными именами. Главная
> проблема - договориться о именах скриптов и их параметрах. Иначе будет
> головная боль с тем, что у каждого производителя UPS они будут свои и не
> очень совместимые между собой. Да, договариваться сложно, уходящий
> корнями в прошлое SIGPWR, выглядит более знакомым и поэтому привлекательным.

Опять-же - ты придумал init.

[Max Nikulin]

On 24/09/2023 20:29, Andrey Jr. Melnikov wrote:
> Поздравляю, ты придумал init в софтине для UPS. Теперь все остальные должны
> знать про неё - а она должна знать про всё остальное.

Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не
расширяют. Мне кажется это странным, если можно запускать в зависимости
от события один из скриптов или скрипт с параметром, который зависит от
события. Решение, что именно делать, принимается вне init (который
процесс PID 1). А скрипт, который позовет демон UPS, вполне может
останавливать и запускать сервисы, менять runlevel, то есть использовать
инфраструктуру SysV init. SIGPWR и дополнительные сигналы при этом не нужны.

Я сейчас глянул
https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELS

> Usage of SIGPWR and /etc/powerstatus is discouraged. Someone wanting to
> interact with init should use the /run/initctl control channel - see the
> initctl(5) manual page for more documentation about this.

То есть даже в SysV init сигнал решили закопать. Что меня смутило, так
это то, что initctl нашелся только в finit. Осталась некоторая
неопределенность, что именно решили сделать в SysV init, но вроде как
раз речь о том, что процессу init (PID 1) не нужно знать, что там с
питанием, это можно делегировать демону UPS и скриптам.

[Andrey Jr. Melnikov]

Max Nikulin <mani...@gmail.com> wrote:
> On 24/09/2023 20:29, Andrey Jr. Melnikov wrote:
> > Поздравляю, ты придумал init в софтине для UPS. Теперь все остальные должны
> > знать про неё - а она должна знать про всё остальное.

> Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не
> расширяют. Мне кажется это странным, если можно запускать в зависимости
> от события один из скриптов или скрипт с параметром, который зависит от
> события. Решение, что именно делать, принимается вне init (который
> процесс PID 1). А скрипт, который позовет демон UPS, вполне может
> останавливать и запускать сервисы, менять runlevel, то есть использовать
> инфраструктуру SysV init. SIGPWR и дополнительные сигналы при этом не нужны.

Вот SIGPWR - это и есть изменение runlevel'а. Только сигналом - а не telinit
или shutdown.
И не надо изоброжать из себя init - для этого он уже есть. Это его задача -
знать, как запустить или остановить всё то, что а) запущено здесь и сейчас,
б) прописано в target/скриптике/rc.pf.d/где-то-там-еще.

> Я сейчас глянул
> https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELS

> > Usage of SIGPWR and /etc/powerstatus is discouraged. Someone wanting to
> > interact with init should use the /run/initctl control channel - see the
> > initctl(5) manual page for more documentation about this.

> То есть даже в SysV init сигнал решили закопать. Что меня смутило, так
> это то, что initctl нашелся только в finit. Осталась некоторая
> неопределенность, что именно решили сделать в SysV init, но вроде как
> раз речь о том, что процессу init (PID 1) не нужно знать, что там с
> питанием, это можно делегировать демону UPS и скриптам.

Это отдельный подвид альтернативно одарённых. Мало ли, что они там не
рекомендуют - интерфейс есть, и доступен без знаний "какой там magic надо
послать в /run/initctl в каком-то-там namespace". Да и сами они не
удосужились написать в свой-же telinit поддержку своего-же
INIT_CMD_(POWERFAIL|POWERFAILNOW|POWEROK).

Это всё показатель того, что эта часть вообще никому не нужна. Все теперь
стоят в DC сертифицированных по Tier-III, где проблемы с электропитанием
решаются оборудованием DC, а получить состояние питания - невозможно в
принципе. А на процент пользователей с домашним UPS - наплевать, они и сами
себе запилят что надо и как надо.

[Victor Wagner]

В Mon, 25 Sep 2023 00:04:03 +0700
Max Nikulin <mani...@gmail.com> пишет:

> On 24/09/2023 20:29, Andrey Jr. Melnikov wrote:
> > Поздравляю, ты придумал init в софтине для UPS. Теперь все
> > остальные должны знать про неё - а она должна знать про всё
> > остальное.
>
> Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не
> расширяют. Мне кажется это странным, если можно запускать в

Если хороший интерфейс расширить, он станет посредственным, а то и
плохим
--
Victor Wagner <vi...@wagner.pp.ru>

[Max Nikulin]

On 24/09/2023 17:00, Михаил Касаджиков wrote:
> Для того чтобы демон ИБП мог потушить весь сервер ему нужны
> соответствующие права, а он может быть запущен с понижением привилегий.
> И послать сигнал SIGPWR иниту он может, а вот уже запустить
> /sbin/shutdown — рожей не вышел.

Не могу сообразить, что именно я пропустил. Послать сигнал init тоже
может не любой процесс. Вызвать kill может любой, но в ответ может
получить EPERM. Иначе любой взбесившийся php скрипт на shared hosting
мог бы слать сигналы init. Или считается, что оставить демону UPS
CAP_KILL это приемлемое решение, а сделать так, чтобы пользователь, под
которым работает этот демон, мог выполнить фиксированную команду, уже плохо?

[Max Nikulin]

On 25/09/2023 16:42, Victor Wagner wrote:
> В Mon, 25 Sep 2023 00:04:03 +0700

> Max Nikulin пишет:

>>
>> Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не
>> расширяют. Мне кажется это странным, если можно запускать в
>
> Если хороший интерфейс расширить, он станет посредственным, а то и
> плохим

Я не могу вспомнить, по какому поводу я когда-то давно лазил в
/etc/inittab, то ли respawn кому-то был нужен, то ли еще что. Но почитав
вчера
https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELS
я перестал понимать, куда его дальше-то расширять? Вроде наоборот хотят
сузить, выкинув /etc/powerstatus, по которому определяется, какой из 3
скриптов запускать по SIGPWR

> If init is not in single user mode and receives a powerfail signal
> (SIGPWR), it reads the file /etc/powerstatus. It then starts a command
> based on the contents of this file:
>
> F(AIL)
> Power is failing, UPS is providing the power. Execute the powerwait
> and powerfail entries.
> O(K)
> The power has been restored, execute the powerokwait entries.
> L(OW)
> The power is failing and the UPS has a low battery. Execute the
> powerfailnow entries.

Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей
точки зрения, не лучше.

On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
> Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том,
> что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
> появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
> разговор о прогрессе и удобстве.

Это про systemd было.

[Михаил Касаджиков]

В понедельник 25 сентябрь 2023 15:11:04 (+03:00), Max Nikulin пишет:

Ну отправит иниту кто угодно сигнал SIGPWR, запустит инит соответствующий скрипт, тот, в свою очередь увидит что нет причин для беспокойства и ничего не сделает. Опять же, в те времена, когда всё это придумывали, не было shared hosting в его нынешнем виде. Другое дело что всю эту систему до ума не довели, вот и имеем то что имеем — ПО для ИБП предпочитает всё делать самостоятельно.

[Andrey Jr. Melnikov]

Max Nikulin <mani...@gmail.com> wrote:

> On 25/09/2023 16:42, Victor Wagner wrote:
> > В Mon, 25 Sep 2023 00:04:03 +0700
> > Max Nikulin пишет:
> >>
> >> Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не
> >> расширяют. Мне кажется это странным, если можно запускать в
> >
> > Если хороший интерфейс расширить, он станет посредственным, а то и
> > плохим

> Я не могу вспомнить, по какому поводу я когда-то давно лазил в
> /etc/inittab, то ли respawn кому-то был нужен, то ли еще что. Но почитав
> вчера
> https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELS
> я перестал понимать, куда его дальше-то расширять? Вроде наоборот хотят
> сузить, выкинув /etc/powerstatus, по которому определяется, какой из 3
> скриптов запускать по SIGPWR

Даа, читал ты его явно по диагонали. Сейчас POWEROK событие выглядит так -
записать OK в /etc/powerstatus (по старому стилю, с 2010 гда - устарело) или
в /var/run/powerstatus (по новому) и послать SIGPWR сигнал - тогда init
запустит нужный скрипт. Или воспользоваться вторым интерфейсом - записать в
управляющий FIFO /run/initctl управляющую структуру из int'ов (без
конкретного указания размерности, хахаха) нужный набор данных.
А я предлагал сделать проще - весь этот цирк с конями дополнить сигналами.

> > If init is not in single user mode and receives a powerfail signal
> > (SIGPWR), it reads the file /etc/powerstatus. It then starts a command
> > based on the contents of this file:
> >
> > F(AIL)
> > Power is failing, UPS is providing the power. Execute the powerwait
> > and powerfail entries.
> > O(K)
> > The power has been restored, execute the powerokwait entries.
> > L(OW)
> > The power is failing and the UPS has a low battery. Execute the
> > powerfailnow entries.
> Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей
> точки зрения, не лучше.

Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся эта
пляска вокруг файликов с сигналами и FIFO?

> On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
> > Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том,
> > что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
> > появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
> > разговор о прогрессе и удобстве.

> Это про systemd было.

Увы, в systemd тоже этого не сделали.

[Max Nikulin]

On 25/09/2023 22:23, Михаил Касаджиков wrote:
> Ну отправит иниту кто угодно сигнал SIGPWR, запустит инит
> соответствующий скрипт, тот, в свою очередь увидит что нет причин для
> беспокойства и ничего не сделает. Опять же, в те времена, когда всё это
> придумывали, не было shared hosting в его нынешнем виде. Другое дело что
> всю эту систему до ума не довели, вот и имеем то что имеем — ПО для ИБП
> предпочитает всё делать самостоятельно.

kill -PWR 1
bash: kill: (1) - Operation not permitted

Ну не может такого быть, чтобы в многопользовательской системе любой
непривилегированный процесс мог послать сигнал любому другому процессу.
И в те времена, когда придумывали сигналы, UNIX был
многопользовательским. Я потому и переспросил.

[Eugene Berdnikov]

On Tue, Sep 12, 2023 at 10:55:46PM +0300, Eugene Berdnikov wrote:
> On Sun, Sep 10, 2023 at 11:02:39PM +0700, Max Nikulin wrote:
[...]
> > > Мои попытки сделать в скрипте цикл и на каждой итерации проверять,
> > > запустился rsyslogd или нет, не привели к успеху даже в варианте
> > > "5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали
> > > случаи, когда процесс не запускался. Автоподъём по крону эту проблему
> > > решает, но нужно понимать, что иногда система живёт без сислога.
> >
> > А оригинальный init скрипт с этой задачей не справлялся что-ли? Какие-то
> > сложности с сетевыми сокетами или что-то другое?
>
> Вытащил скрипт из свежего orphan-sysvinit-scripts, о котором я не знал.
> Там скрипт совсем свеженький, датирован 3 сентября 2023. При сравнении
> с моим собственным скриптом (последняя правка от 30-янв-2022) нашлось
> лишь одно отличие: у меня start-stop-daemon вызывается с опцией -oknodo,
> в остальном скрипты по сути совпадают. И выяснилось, что сейчас оба
> успешно перезапускают rsyslogd... :)

Но не тут-то было: сегодня 4 раза подряд rsyslogd не запустился... :)
На том же хосте, где 2 недели назад проверялся orphan-sysvinit-scripts.

> В чём была проблема -- мне тогда
> докопаться не удалось (уже не помню, почему, кажется, под strace эта
> зараза всегда успешно работала, а без strace процесс исчезал, не оставляя
> ни корки, ни других следов). Возможно, багу пофиксили, поскольку ryslog
> с тех пор обновлялся, в том числе совсем недавно:
>
> 2023-08-19 21:42:26 upgrade rsyslog:i386 8.2306.0-2 8.2308.0-1
> --
> Eugene Berdnikov

--
Eugene Berdnikov

[Max Nikulin]

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 сигнала и остановились на варианте, который сейчас
выглядит несколько вычурным.

Послать-то сигнал может и просто, а вот правильно поймать уже некоторое
искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я
сигналы не люблю.

С сокетами проще. Если есть утилита и библиотека, которые могут слать
нужные сообщения, и процесс их может правильно обработать, то это лучше,
чем сигналы. Мне такой вариант нравится больше.

А вообще, можно и полностью избавить init от кода, специфичного для
обработки событий питания. Все равно это сводится к более общему и
универсальному интерфейсу "запустить команду с параметрами". Вот пусть
демон UPS и просит выполнить один из вариантов "powerfail start",
"powerfail now", "powerfail stop" (ну или что-то похожее) прямым текстом
без эфвемизмов вроде нумерованных сигналов.

>> On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
>>> Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том,
>>> что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
>>> появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
>>> разговор о прогрессе и удобстве.
>
>> Это про systemd было.
> Увы, в systemd тоже этого не сделали.

Я бы еще понял ругань, что в systemd отломали старые интерфейсы. С
ininctl вообще какой-то абсурд. Он сообщения понимает, но просто плюется
в логи, что обновляйте свой UPS.

Cигналов в systemd как раз выше крыши:

On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:

> Да, задизайнить
> SIGRTMIN+4 в poweroff и SIGRTMIN+14 в immediate poweroff - смог

Ну вот 2 сигнала уже есть. Точнее там другая интерпретация SIGPWR:
готовьтесь, питание может кончится, а запускаемые скрипты уже могут
что-то делать, хоть тот же powerstatus читать.

Если питание вернулось, то для этого есть

SIGRTMIN+0
Enters default mode, starts the default.target unit.
This is mostly equivalent to systemctl isolate default.target.

Ну просто мечта любителя сигналов.

[Max Nikulin]

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).

[Eugene Berdnikov]

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

[Andrey Jr. Melnikov]

Max Nikulin <mani...@gmail.com> 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.

[Andrey Jr. Melnikov]

Это стандартный кусок записи внутреннего сообщения в лог. Ничего интересного
тут нет. Самое интересное - почему сдох слушатель, но этого в трейсе у тебя
нет.

> Возможно, этот сокет с 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 ---

[Eugene Berdnikov]

On Thu, Sep 28, 2023 at 11:52:49PM +0300, Andrey Jr. Melnikov wrote:
> > и он перед экзитом выполняет такой код:
>
> > [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(2).

> Ничего интересного
> тут нет. Самое интересное - почему сдох слушатель, но этого в трейсе у тебя
> нет.

Трейс там длинный, и чудесами типа вызова exit(2) из дочернего треда,
и где там должен быть слушатель вообще непонятно (ведь коннектился он
к этому сокету не тогда, когда я запустил strace, а несколькими часами
раньше).

> > Возможно, этот сокет с fd=1 используется для взаимодействия со своими же
> Это явно результат вызова openlog() где-то внутри syslog().

Я догадываюсь, но syslogd, вызывающий openlog(), это форменная шиза...
Ты не считаешь, что автора такого изделия нужно везти в психушку? :)
--
Eugene Berdnikov

[Eugene Berdnikov]

On Thu, Sep 28, 2023 at 11:30:47PM +0300, Andrey Jr. Melnikov wrote:
> Max Nikulin <mani...@gmail.com> wrote:
> > Послать-то сигнал может и просто, а вот правильно поймать уже некоторое
> > искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я
> > сигналы не люблю.
> Вот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы -
> хорошее, правильное асинхронное средство донести до процесса необходимую
> информацию.

Информация там очень скудна, по сути исчерпывается списком сигналов
(с некоторыми вольностями в трактовке, включая USR1/USR2).

> > С сокетами проще. Если есть утилита и библиотека, которые могут слать
> > нужные сообщения, и процесс их может правильно обработать, то это лучше,
> > чем сигналы. Мне такой вариант нравится больше.
> Проще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать
> ошибки, прочитать сокет (если прочитается), закрыть сокет.. и это все вместо
> одного signal handler?

Ой, не надо сказки про "один signal handler"... Он один, когда нужно
застрелицца. Да и то если твоя прога ничего полезного не делает, так что
может просто не обрабатывать этот сигнал. А во всех нетривиальных случаях
хэндлер может лишь поставить флаг в переменной, описанной как sig_atomic_c
(static volatile ...) и вернуться через sigreturn(). Потому как любое
действие, затрагивающее libc, грозит разносом стэка, и вообще во время
обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся,
нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом
с poll/select будет ещё вычитывание той переменной, с флагом. Когда же она
вычитана и мы знаем, что сигнал получен, встанет отдельный квест, как
эту переменную безопасно вычистить, чтобы не потерять повторный сигнал,
который может придти именно в момент очистки. Такое вполне может быть,
если это не SIGTERM, который обычно одиночный и повторение которого
ничего не меняет.

По сравнению с этим добавление в poll/select одного сокета, на котором
принимаются команды управления, это просто детская задачка.

Сигналы хороши тем, что на вычитывание своего флага не нужен дорогущий
сискол. Поэтому мониторингом сигналов можно нашпиговать самые горячие
участки кода. Но и цена грамотного программирования здесь очень высока.
Особенно если программа многопоточная.
--
Eugene Berdnikov

[Maksim Dmitrichenko]

вт, 26 сент. 2023 г. в 11:24, Andrey Jr. Melnikov <temno...@gmail.com>:

А я предлагал сделать проще - весь этот цирк с конями дополнить сигналами.

.... 

Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся эта
пляска вокруг файликов с сигналами и FIFO?

Хуже API, чем API на сигналах, придумать, кажется, трудно. Сигналы - это, если откровенно, костыль придуманный во времена керниганозоя, который к тому же сильно портит концепцию, что в UNIX всё либо процесс, либо файл, ибо сигнал - ни то, ни другое, его нельзя ждать селектом (новомодный signalfd не в счёт). Хэндлер сигнала - это особенная сущность, практически как обработчик прерывания уровня ядра, где много чего нельзя. Сигналы с потоками требуют дополнительных мер работы. Сигналы не накапливаются в очередь. Если хотите сделать API, то сигналы - прекрасный антипаттерн.

--

With best regards
  Maksim Dmitrichenko

[Maksim Dmitrichenko]

пт, 29 сент. 2023 г. в 12:37, Eugene Berdnikov <b...@protva.ru>:

 Потому как любое
 действие, затрагивающее libc, грозит разносом стэка, и вообще во время
 обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся,
 нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом
 с poll/select будет ещё вычитывание той переменной, с флагом.

Это тоже не совсем так. Во-первых, man 7 signal-safety содержит список async signal safe функций, которые можно дергать из обработчика сигнала. Во-вторых, трюк с глобальным флагом - он так себе, обычно либо в пайп писали из обработчика сигнала, который ждали на том самом select'е (и тогда вопрос: нахрена танцы с сигналами, если сразу можно писать в socket?), либо в sem_post делали, который можно делать из обработчкика, но semaphore по старой доброй UNIX-традиции - это либо файл, либо процесс (нет), поэтому его никак не должаться в select/poll.

-

[Max Nikulin]

On 28/09/2023 21:09, Eugene Berdnikov wrote:
> On Thu, Sep 28, 2023 at 05:32:35PM +0700, Max Nikulin wrote:
>> Останавливается перед этим нормально?
>
> Ммм... не знаю. Он при остановке что-то странное делает.

Я скорее про то, что не остается ли старого pid-файла или еще
какого-нибудь мусора. Проблем с таймаутом, чтобы заново открыть сетевой
сокет, вроде быть не должно.

> # sysctl -a | fgrep kernel.core
> kernel.core_pattern = core

Проблем с записью в cwd у rsyslog вроде не ожидается, но можно указать
полный путь.

> kernel.core_pipe_limit = 0
> kernel.core_uses_pid = 0
>
> # ulimit -c
> unlimited
>
> # limit coredumpsize
> coredumpsize unlimited

Я бы смотрел именно у работающего процесса с помощью prlimit.

Проверить, не осталось ли ограницений, можно с помощью "kill -ABRT" (и
удалить core после этого). На самом деле, я не особенно верю в segfault.

> Перезапускаем (/etc/init.d/rsyslog restart) и ура, с первого раза поймали.

Куда-нибудь типа dmesg или в консоль никакие сообщения не попадают? Что
если обернуть запуск, перенаправив stderr и stdout в файл, в надежде,
что сругается до того, как станет демоном и отцепится. Совсем тихая
смерть выглядит немного странно.

[Max Nikulin]

Откуда столько яда? Жизнь штука разнообразная. Сообщение об остановке
rsyslog вполне может осесть в логах:

journalctl -b -1 -u rsyslog
... rsyslogd[1108]: [origin software="rsyslogd" swVersion="8.2302.0"
x-pid="1108" x-info="https://www.rsyslog.com"] exiting on signal 15.

Вообще у rsyslog несколько вродных модулей, откуда он может читать
сообщения. /dev/log один из них, и может быть отключен в конфигурации.

syslog(3) пытается открыть сокет заново, если попытка записи туда не
удалась. Сделано это на случай того, что с прошлого вызова функции демон
syslog перезапускался.

Так что выглядит все штатно. Ну не получилось отправить сообщение в лог,
потому что /dev/log в данном случае слушал сам rsyslog и уже закрыл сокет.

[Eugene Berdnikov]

On Fri, Sep 29, 2023 at 12:53:28PM +0400, Maksim Dmitrichenko wrote:
> пт, 29 сент. 2023 г. в 12:37, Eugene Berdnikov <[1]b...@protva.ru>:

>
> >  Потому как любое
> >  действие, затрагивающее libc, грозит разносом стэка, и вообще во время
> >  обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся,
> >  нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом
> >  с poll/select будет ещё вычитывание той переменной, с флагом.
>
> Это тоже не совсем так. Во-первых, man 7 signal-safety содержит список
> async signal safe функций, которые можно дергать из обработчика сигнала.

Ну так наличие схемы раскладки мин не отменяет сам факт наличия минного
поля, а также риска подорваться на нём. Прозевать мину тут легче лёгкого.

> Во-вторых, трюк с глобальным флагом - он так себе, обычно либо в пайп
> писали из обработчика сигнала, который ждали на том самом select'е (и

Запись в пайп это сисколл, а потому очень долго и неэффективно. Повторю:
сигналы хороши там, где нужна быстрая реакция, в самые горячих точках кода.
Если это не нужно, то poll/select намного проще. Тут мы расходимся во
взглядах с А.Мельниковым.
--
Eugene Berdnikov

[Maksim Dmitrichenko]

пт, 29 сент. 2023 г. в 14:50, Eugene Berdnikov <b...@protva.ru>:

 Запись в пайп это сисколл, а потому очень долго и неэффективно. Повторю:
 сигналы хороши там, где нужна быстрая реакция, в самые горячих точках кода.
 Если это не нужно, то poll/select намного проще. Тут мы расходимся во
 взглядах с А.Мельниковым.

Ну про своё отношение к сигналам я уже написал в первом письме в этот тред. Производительное API на сигналах всё равно не сделать толком, так как два и более последовательно пришедших сигнала в одном дельта-интервале будут расценены как один. Поэтому городить такую схему можно, если это довольно редкое событие. А если оно редкое, то пёс с ним - этот один лишний системный вызов.

--

[Eugene Berdnikov]

On Fri, Sep 29, 2023 at 12:44:46PM +0400, Maksim Dmitrichenko wrote:
> Сигналы не накапливаются в очередь.

Мне казалось, что вполне себе накапливаются, при SA_RESTART.
В манах эта модель поведения называется "BSD semantics".
Модель без накопления называется "SysV semantics".
Можно выбрать алгоритм для конкретного сигнала.

А для совершенно отмороженных экстремалов, желающих получать сигналы
даже в сигхэндлере, есть SA_NODEFER, рекомендую. :)
--
Eugene Berdnikov

[Eugene Berdnikov]

On Fri, Sep 29, 2023 at 09:57:29PM +0400, Maksim Dmitrichenko wrote:
> Очередь есть только у RT-сигналов.

>
> >  В манах эта модель поведения называется "BSD semantics".
> >  Модель без накопления называется "SysV semantics".
> >  Можно выбрать алгоритм для конкретного сигнала.
>

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

Перечитал ещё раз man и да, признаю свою ошибку. Согласен.
--
Eugene Berdnikov