devuan
В букворме сломана поддержка 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.
Re: devuan
On Thu, Sep 07, 2023 at 01:38:27AM +0300, sergio 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 исправить (на > rsyslog-rotate ссылается /etc/logrotate.d/rsyslog), то есть update оно > переживать будет. А можно и по сторонам посмотреть. Есть у кого чего сказать > про devuan? Не знаю про 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
Re: devuan
On Thu, 7 Sep 2023 01:38:27 +0300 sergio wrote: > Есть у кого чего сказать про devuan? Ну, у меня он на домашней машине стоит (там микс из девуановских репозиториев и deb-multimedia). Работает нормально, но, апстрим может погдадить. Так, например, недавно libgudev поломало совместимость с eudev (подробности: https://github.com/eudev-project/eudev/issues/249).
Re: devuan
sergio 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. Классическое "К соседу в сарай через Никарагуа".
Re: devuan
On 2023-09-07 04:09, Eugene Berdnikov wrote: Rsyslog переломан в нескольких местах. Если не ошибаюсь, то в последнем (12) Дебьяне rsyslog по умолчанию не ставится и стоит только системный журнал из systemd... https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm
Re: devuan
On Thu, 7 Sep 2023 14:11:06 +0300 "Andrey Jr. Melnikov" 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
Re: devuan
On 08/09/2023 03:31, Tim Sattarov wrote: On 2023-09-07 04:09, Eugene Berdnikov wrote: Rsyslog переломан в нескольких местах. Если не ошибаюсь, то в последнем (12) Дебьяне rsyslog по умолчанию не ставится и стоит только системный журнал из systemd... https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm Тогда уж 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, чтобы напомнить администратору, что ротацию логов надо чинить.
Re: devuan
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
Re: devuan
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 скрипт с этой задачей не справлялся что-ли? Какие-то сложности с сетевыми сокетами или что-то другое?
Re: devuan
07.09.2023 15:09, Eugene Berdnikov пишет: Единственная известная мне альтернатива rsyslog-у, умеющая делить логи по шаблонам/регуляркам, это syslog-ng. К сожалению, сейчас его автора, что называется, понесло... А раньше syslog-ng иногда подвисал из-за какой-то баги. При этом он переставал принимать пакеты, и подвисала практически вся система, ибо в юниксах код syslog(3) традиционно блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все материалы для багрепорта, но времени оформить его не хватило, пришлось просто оставить syslog-ng. Альтернатива в виде rsyslog'а хоть с костылями и через пень-колоду, но всё-таки работает и не убивает всю систему. Можно поподробнее про syslog-ng ? используем syslog-ng на большом количестве серверов со стретча до булзая, в разных позах - никаких проблем не замечали
Re: devuan
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 18274root 32u unix 0xc94137a7 0t05922798 type=DGRAM Т.е. syslog-ng пытается писать в сокет, клонированный accept()ом от /dev/log. Но с обратной стороны никто не собирается читать, там сидит чукча-писатель с syslog(3). А поскольку send() с MSG_NOSIGNAL, и, ясный пень, без таймера, то наступает капец. Ни по ssh зайти на эту машину, ни с консоли, поскольку и sshd, и getty->login вызывают синхронный syslog(3), на котором точно так же виснут. Бага проявлялась редко, но на физических хостах она отличалась особой неприятностью. И неуловимостью. А в контейнере поймалась на ура. Возможно, это уже починили, всё-таки 4 года прошло. -- Eugene Berdnikov
Re: devuan
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
Re: devuan
Eugene Berdnikov 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.
Re: devuan
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
Re: devuan
Eugene Berdnikov 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/0S+ 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/0S+ 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/0S+ 0:00 grep cron ~# start-stop-daemon --status --exec /usr/sbin/cron ; echo $? 3 О. Теперь мы заметили, что "program is not running". Вот такая чудная запускалка демонов.
Re: devuan
On Thu, Sep 14, 2023 at 02:26:07PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov 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
Re: devuan
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 $? почему оно должно путаться - я вообще не понимаю
Re: devuan
Eugene Berdnikov wrote: > On Thu, Sep 14, 2023 at 02:26:07PM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov 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 - вынь да полож.
Re: devuan
dimas wrote: > 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 $? > почему оно должно путаться - я вообще не понимаю Во первых - это был пример. Во вторых - не каждый демон первым делом создаёт pid файл, он может задуматься на ресолвинге имён или ещё каких своих потребностях. И в обратную сторону так-же - демон останавливается, pid уже стёр, а сам ещё не выгрузился. Поэтому - демон afrnbxtcrb запущен, а pid-файла - нет.
Re: devuan
On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov 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
Re: devuan
Eugene Berdnikov wrote: > On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov 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 "просто поставь его" - это не наш метод.
Re: devuan
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/0S+ 0:00 grep cron А научить его действительно проблема? Наугад попробовал ps -eo pid,pidns,user,cmd f контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc вроде создает, так что это влиять не должно.
Re: devuan
On Fri, Sep 15, 2023 at 05:03:50PM +0300, Andrey Jr. Melnikov wrote: > Eugene Berdnikov 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
Re: devuan
Max Nikulin wrote: > 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/0S+ 0:00 grep cron > А научить его действительно проблема? Наугад попробовал > ps -eo pid,pidns,user,cmd f > контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc > вроде создает, так что это влиять не должно. Нет, не проблема. Проблема написать баг-репорт и донести его нужность до маинтайнеров, у которых теперь есть на всё одна отмазка "sysvinit устарел, под systemd всё работает (C)".
Re: devuan
Eugene Berdnikov wrote: > On Fri, Sep 15, 2023 at 05:03:50PM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov 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. Иннновации, ё!
Re: devuan
On Tue, Sep 19, 2023 at 10:02:00AM +0300, Andrey Jr. Melnikov wrote: > Max Nikulin wrote: > > контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc > > вроде создает, так что это влиять не должно. > > Нет, не проблема. Проблема написать баг-репорт и донести его нужность до > маинтайнеров, у которых теперь есть на всё одна отмазка "sysvinit устарел, > под systemd всё работает (C)". Писать лучше патч, с ним багрепорт имеет намного больше шансов на успех. Хотя и это не всегда помогает... -- Eugene Berdnikov
Re: devuan
On 19/09/2023 14:17, Eugene Berdnikov wrote: On Tue, Sep 19, 2023 at 10:02:00AM +0300, Andrey Jr. Melnikov wrote: Max Nikulin wrote: контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc вроде создает, так что это влиять не должно. Нет, не проблема. Проблема написать баг-репорт и донести его нужность до маинтайнеров, у которых теперь есть на всё одна отмазка "sysvinit устарел, под systemd всё работает (C)". Писать лучше патч, с ним багрепорт имеет намного больше шансов на успех. Хотя и это не всегда помогает... Я бы еще добавил, что договариваться надо скорее с разработчиками, которые сейчас поддерживают start-stop-daemon, чем с сопровождающими пакет. Странное ощущение возникло от этого обсуждения. Участники вдоволь оттоптались на граблях, представляют, в каком месте надо чинить, вроде есть возможность проверить, что исправленная версия будет правильно работать, но заниматься этим должен кто-то другой, у кого, возможно, времени хватает только на то, чтобы следить, что под systemd работает. P.S. А если демон намеренно решил самоизолироваться в своем pidns? Не сравняется ли в результате SysV init по развесистости с systemd, если учесть все эти нюансы?
Re: devuan
On 19/09/2023 14:00, Andrey Jr. Melnikov wrote: Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том, что питание пропало, SIGRTMIN+x1 для информирования о том, что питание появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы разговор о прогрессе и удобстве. Лично у меня сомнения, что этим должен заниматься именно init. Вроде задача для пользовательского процесса, который сходит спросит, сколько заряда осталось у аккумулятора, а потом уже будет решать, на сколько спешно надо останавливать систему. В ноутбуках акселерометры, по которым можно парковать головки жесткого диска при падении, доступны просто как файлы в /sys. Реакция на событие нужна за доли секунды, а init для этого не обязателен. Не убедительно, что сообщать о пропадании/восстановлении питания надо именно разными сигналами.
Re: devuan
Max Nikulin 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 это тоже всё решалось и решается, только вот скриптик будет разляпистее.
Re: devuan
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, выглядит более знакомым и поэтому привлекательным.
Re: devuan
Для того чтобы демон ИБП мог потушить весь сервер ему нужны соответствующие права, а он может быть запущен с понижением привилегий. И послать сигнал SIGPWR иниту он может, а вот уже запустить /sbin/shutdown — рожей не вышел. В воскресенье 24 сентябрь 2023 10:58:55 (+03:00), 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, > выглядит более знакомым и поэтому привлекательным. > >
Re: devuan
Max Nikulin 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.
Re: devuan
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 и скриптам.
Re: devuan
Max Nikulin 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 - наплевать, они и сами себе запилят что надо и как надо.
Re: devuan
В Mon, 25 Sep 2023 00:04:03 +0700 Max Nikulin пишет: > On 24/09/2023 20:29, Andrey Jr. Melnikov wrote: > > Поздравляю, ты придумал init в софтине для UPS. Теперь все > > остальные должны знать про неё - а она должна знать про всё > > остальное. > > Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не > расширяют. Мне кажется это странным, если можно запускать в Если хороший интерфейс расширить, он станет посредственным, а то и плохим -- Victor Wagner
Re: devuan
On 24/09/2023 17:00, Михаил Касаджиков wrote: Для того чтобы демон ИБП мог потушить весь сервер ему нужны соответствующие права, а он может быть запущен с понижением привилегий. И послать сигнал SIGPWR иниту он может, а вот уже запустить /sbin/shutdown — рожей не вышел. Не могу сообразить, что именно я пропустил. Послать сигнал init тоже может не любой процесс. Вызвать kill может любой, но в ответ может получить EPERM. Иначе любой взбесившийся php скрипт на shared hosting мог бы слать сигналы init. Или считается, что оставить демону UPS CAP_KILL это приемлемое решение, а сделать так, чтобы пользователь, под которым работает этот демон, мог выполнить фиксированную команду, уже плохо?
Re: devuan
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 было.
Re: devuan
В понедельник 25 сентябрь 2023 15:11:04 (+03:00), Max Nikulin пишет: > On 24/09/2023 17:00, Михаил Касаджиков wrote: > > Для того чтобы демон ИБП мог потушить весь сервер ему нужны > > соответствующие права, а он может быть запущен с понижением привилегий. > > И послать сигнал SIGPWR иниту он может, а вот уже запустить > > /sbin/shutdown — рожей не вышел. > > Не могу сообразить, что именно я пропустил. Послать сигнал init тоже может не > любой процесс. Вызвать kill может любой, но в ответ может получить EPERM. > Иначе любой взбесившийся php скрипт на shared hosting мог бы слать сигналы > init. Или считается, что оставить демону UPS CAP_KILL это приемлемое решение, > а сделать так, чтобы пользователь, под которым работает этот демон, мог > выполнить фиксированную команду, уже плохо? Ну отправит иниту кто угодно сигнал SIGPWR, запустит инит соответствующий скрипт, тот, в свою очередь увидит что нет причин для беспокойства и ничего не сделает. Опять же, в те времена, когда всё это придумывали, не было shared hosting в его нынешнем виде. Другое дело что всю эту систему до ума не довели, вот и имеем то что имеем — ПО для ИБП предпочитает всё делать самостоятельно.
Re: devuan
Max Nikulin 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 тоже этого не сделали.
Re: devuan
On 25/09/2023 22:23, Михаил Касаджиков wrote: Ну отправит иниту кто угодно сигнал SIGPWR, запустит инит соответствующий скрипт, тот, в свою очередь увидит что нет причин для беспокойства и ничего не сделает. Опять же, в те времена, когда всё это придумывали, не было shared hosting в его нынешнем виде. Другое дело что всю эту систему до ума не довели, вот и имеем то что имеем — ПО для ИБП предпочитает всё делать самостоятельно. kill -PWR 1 bash: kill: (1) - Operation not permitted Ну не может такого быть, чтобы в многопользовательской системе любой непривилегированный процесс мог послать сигнал любому другому процессу. И в те времена, когда придумывали сигналы, UNIX был многопользовательским. Я потому и переспросил.
Re: devuan
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
Re: devuan
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. Ну просто мечта любителя сигналов.
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).
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
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
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
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
Re: devuan
On Thu, Sep 28, 2023 at 11:30:47PM +0300, Andrey Jr. Melnikov wrote: > Max Nikulin wrote: > > Послать-то сигнал может и просто, а вот правильно поймать уже некоторое > > искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я > > сигналы не люблю. > Вот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы - > хорошее, правильное асинхронное средство донести до процесса необходимую > информацию. Информация там очень скудна, по сути исчерпывается списком сигналов (с некоторыми вольностями в трактовке, включая USR1/USR2). > > С сокетами проще. Если есть утилита и библиотека, которые могут слать > > нужные сообщения, и процесс их может правильно обработать, то это лучше, > > чем сигналы. Мне такой вариант нравится больше. > Проще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать > ошибки, прочитать сокет (если прочитается), закрыть сокет.. и это все вместо > одного signal handler? Ой, не надо сказки про "один signal handler"... Он один, когда нужно застрелицца. Да и то если твоя прога ничего полезного не делает, так что может просто не обрабатывать этот сигнал. А во всех нетривиальных случаях хэндлер может лишь поставить флаг в переменной, описанной как sig_atomic_c (static volatile ...) и вернуться через sigreturn(). Потому как любое действие, затрагивающее libc, грозит разносом стэка, и вообще во время обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся, нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом с poll/select будет ещё вычитывание той переменной, с флагом. Когда же она вычитана и мы знаем, что сигнал получен, встанет отдельный квест, как эту переменную безопасно вычистить, чтобы не потерять повторный сигнал, который может придти именно в момент очистки. Такое вполне может быть, если это не SIGTERM, который обычно одиночный и повторение которого ничего не меняет. По сравнению с этим добавление в poll/select одного сокета, на котором принимаются команды управления, это просто детская задачка. Сигналы хороши тем, что на вычитывание своего флага не нужен дорогущий сискол. Поэтому мониторингом сигналов можно нашпиговать самые горячие участки кода. Но и цена грамотного программирования здесь очень высока. Особенно если программа многопоточная. -- Eugene Berdnikov
Re: devuan
вт, 26 сент. 2023 г. в 11:24, Andrey Jr. Melnikov : > А я предлагал сделать проще - весь этот цирк с конями дополнить сигналами. > > Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся эта > пляска вокруг файликов с сигналами и FIFO? > Хуже API, чем API на сигналах, придумать, кажется, трудно. Сигналы - это, если откровенно, костыль придуманный во времена керниганозоя, который к тому же сильно портит концепцию, что в UNIX всё либо процесс, либо файл, ибо сигнал - ни то, ни другое, его нельзя ждать селектом (новомодный signalfd не в счёт). Хэндлер сигнала - это особенная сущность, практически как обработчик прерывания уровня ядра, где много чего нельзя. Сигналы с потоками требуют дополнительных мер работы. Сигналы не накапливаются в очередь. Если хотите сделать API, то сигналы - прекрасный антипаттерн. -- With best regards Maksim Dmitrichenko
Re: devuan
пт, 29 сент. 2023 г. в 12:37, Eugene Berdnikov : > Потому как любое > действие, затрагивающее libc, грозит разносом стэка, и вообще во время > обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся, > нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом > с poll/select будет ещё вычитывание той переменной, с флагом. Это тоже не совсем так. Во-первых, man 7 signal-safety содержит список async signal safe функций, которые можно дергать из обработчика сигнала. Во-вторых, трюк с глобальным флагом - он так себе, обычно либо в пайп писали из обработчика сигнала, который ждали на том самом select'е (и тогда вопрос: нахрена танцы с сигналами, если сразу можно писать в socket?), либо в sem_post делали, который можно делать из обработчкика, но semaphore по старой доброй UNIX-традиции - это либо файл, либо процесс (нет), поэтому его никак не должаться в select/poll. - With best regards Maksim Dmitrichenko
Re: devuan
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 coredumpsizeunlimited Я бы смотрел именно у работающего процесса с помощью prlimit. Проверить, не осталось ли ограницений, можно с помощью "kill -ABRT" (и удалить core после этого). На самом деле, я не особенно верю в segfault. Перезапускаем (/etc/init.d/rsyslog restart) и ура, с первого раза поймали. Куда-нибудь типа dmesg или в консоль никакие сообщения не попадают? Что если обернуть запуск, перенаправив stderr и stdout в файл, в надежде, что сругается до того, как станет демоном и отцепится. Совсем тихая смерть выглядит немного странно.
Re: devuan
On 29/09/2023 13:45, Eugene Berdnikov wrote: On Thu, Sep 28, 2023 at 11:52:49PM +0300, Andrey Jr. Melnikov wrote: Это явно результат вызова openlog() где-то внутри syslog(). Я догадываюсь, но syslogd, вызывающий openlog(), это форменная шиза... Ты не считаешь, что автора такого изделия нужно везти в психушку? :) Откуда столько яда? Жизнь штука разнообразная. Сообщение об остановке 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 и уже закрыл сокет.
Re: devuan
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
Re: devuan
пт, 29 сент. 2023 г. в 14:50, Eugene Berdnikov : > Запись в пайп это сисколл, а потому очень долго и неэффективно. Повторю: > сигналы хороши там, где нужна быстрая реакция, в самые горячих точках > кода. > Если это не нужно, то poll/select намного проще. Тут мы расходимся во > взглядах с А.Мельниковым. > Ну про своё отношение к сигналам я уже написал в первом письме в этот тред. Производительное API на сигналах всё равно не сделать толком, так как два и более последовательно пришедших сигнала в одном дельта-интервале будут расценены как один. Поэтому городить такую схему можно, если это довольно редкое событие. А если оно редкое, то пёс с ним - этот один лишний системный вызов. -- With best regards Maksim Dmitrichenko
Re: devuan
On Fri, Sep 29, 2023 at 12:44:46PM +0400, Maksim Dmitrichenko wrote: > Сигналы не накапливаются в очередь. Мне казалось, что вполне себе накапливаются, при SA_RESTART. В манах эта модель поведения называется "BSD semantics". Модель без накопления называется "SysV semantics". Можно выбрать алгоритм для конкретного сигнала. А для совершенно отмороженных экстремалов, желающих получать сигналы даже в сигхэндлере, есть SA_NODEFER, рекомендую. :) -- Eugene Berdnikov
Re: devuan
пт, 29 сент. 2023 г. в 21:44, Eugene Berdnikov : > On Fri, Sep 29, 2023 at 12:44:46PM +0400, Maksim Dmitrichenko wrote: > > Сигналы не накапливаются в очередь. > > Мне казалось, что вполне себе накапливаются, при SA_RESTART. > Из man 7 signal: Standard signals do not queue. If multiple instances of a standard signal are generated while that signal is blocked, then only one instance of the signal is marked as pending (and the signal will be delivered just once when it is unblocked). In the case where a standard signal is already pending, the siginfo_t structure (see sigaction(2)) associated with that signal is not overwritten on arrival of subsequent instances of the same signal. Thus, the process will receive the information associated with the first instance of the signal. Очередь есть только у RT-сигналов. > В манах эта модель поведения называется "BSD semantics". > Модель без накопления называется "SysV semantics". > Можно выбрать алгоритм для конкретного сигнала. ЕМНИП, это касается другого - когда система считает, что сигнал обработан и можно вызывать хендлер опять. -- With best regards Maksim Dmitrichenko
Re: devuan
sergio writes: > В букворме сломана поддержка rsyslog в sysv: > > 1. удалён /etc/init.d/rsyslog > 2. /usr/lib/rsyslog/rsyslog-rotate обрезан else про invoke-rc.d: > > <...> > > Воспринимается это как целенаправленное вредительство и унижение > пользователей sysV. (я конечно архивариус, ага) Да неужели, блин, заметили! Вот ни разу такого за последние 10 лет не было, начиная с голосования в 2014м, и вот опять! =) Ребята, ситуация не изменится, исправлений ждать не приходится. Red Hat контролирует десктопный GNU/Linux как вендор-монополист (и нет, всякие Canonical даже рядом не стояли). И лицензия GPL тут не спасёт, потому что "постоянно развивающийся софт, находящийся вечно на острие прогресса", как показала практика, невозможно форкнуть: и управляет им тот, кто оплачивает труд разработчиков. И совершенно не важно, нужен ли этот труд на самом деле, или нет -- разработка просто должна вестись. Так что вне зависимости от того, что мы вкатываем на свой десктоп, мы жрём то, что даёт вендор. Альтернатива -- это маргинализироваться, уходить с мейнстримных дистрибутивов. Причём это процесс итеративный, и вас будут оттеснять всё дальше и дальше: вот, апстримные правки в Debian в очередной раз Devuan поломали, ну надо же какое дело. Не нравится? Ну так есть более маргинльные дистры. Идите дальше. А потом ещё, и ещё, ещё дальше: Gentoo, Slackware, LFS... Вот вся эта херня... При таких раскладах в FOSS можно ещё с чистой совестью рассмотреть вариант миграции на проприетарные системы.
Re: [S] Re: devuan
On Fri, Sep 29, 2023 at 09:57:29PM +0400, Maksim Dmitrichenko wrote: >Очередь есть только у RT-сигналов. > >> В манах эта модель поведения называется "BSD semantics". >> Модель без накопления называется "SysV semantics". >> Можно выбрать алгоритм для конкретного сигнала. > >ЕМНИП, это касается другого - когда система считает, что сигнал обработан >и можно вызывать хендлер опять. Перечитал ещё раз man и да, признаю свою ошибку. Согласен. -- Eugene Berdnikov
Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)
Victor Wagner writes: > Можно предолжить эту систему проекту devuan или самому дистрибутив > форкнуть. Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве основной системы? У меня всё руки не дойдут. На одной из машин я сейчас держу смешанную систему, но я довыпендривался с репами и, похоже, придётся впервые за 6 лет систему сносить и с нуля накатывать. Вот думаю: перебраться, что ли, на devuan полностью, или опять держать смешанную систему debian/devuan? Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот потеря mpd лично мне не приятна очень. Привык я к нему. Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин под Devuan? signature.asc Description: PGP signature
Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)
У меня стоит и на работе, и на ноутбуке (второй системой, первая Void), и до недавнего времени стояла на настольнике. Перешёл сразу же, как только в Дебиане по умолчанию начали поставлять systemd. Мне вполне сносно живётся, хотя и стоит смесь ceres (sid), ascii (testing) и jessie. Выбешивает разве то, что иногда траблы с обновлениями случаются (boost + mpi, например). Тут уже как душа желает. Можете попробовать. :) вторник, 13 сентября 2016 г. пользователь Dmitrii Kashin написал: > Victor Wagner writes: > >> Можно предолжить эту систему проекту devuan или самому дистрибутив >> форкнуть. > > Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве > основной системы? > > У меня всё руки не дойдут. На одной из машин я сейчас держу смешанную > систему, но я довыпендривался с репами и, похоже, придётся впервые за 6 > лет систему сносить и с нуля накатывать. Вот думаю: перебраться, что ли, > на devuan полностью, или опять держать смешанную систему debian/devuan? > > Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего > выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот > потеря mpd лично мне не приятна очень. Привык я к нему. > > Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин > под Devuan? >
Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)
13 сентября 2016 г., 6:21 пользователь Dmitrii Kashin написал: > > Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве > основной системы? Да, на домашний ноут. Ранее стоял debian/testing. В devuan сломался переход в standby при закрытии крышки, при запуске руками работает. IMHO, это было завязано на systemd. > Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин > под Devuan? Да.
Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)
13 сентября 2016 г., 4:21 пользователь Dmitrii Kashin написал: > Victor Wagner writes: > >> Можно предолжить эту систему проекту devuan или самому дистрибутив >> форкнуть. > > Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве > основной системы? На домашнем ноуте и на рабочем компе. Работает нормально, но у меня и потребностей особых нет. > Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего > выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот > потеря mpd лично мне не приятна очень. Привык я к нему. Э... $ apt-cache policy mpd mpd: Установлен: (отсутствует) Кандидат: 1:0.19.9-dmo2 Таблица версий: 1:0.19.9-dmo2 0 500 http://www.deb-multimedia.org/ jessie/main amd64 Packages 0.19.1-1.1 0 500 http://packages.devuan.org/merged/ jessie/main amd64 Packages -100 http://httpredir.debian.org/debian/ jessie/main amd64 Packages Вроде никто никуда не выкидывал. При установке поставится libsystemd0, но для работы сам systemd не требуется. > Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин > под Devuan? Стоит. Правда, мне пришлось для того, чтобы работал apt-file search, делать следующее: deb [targets=Translations] http://httpredir.debian.org/debian jessie main contrib non-free так как в merged репозитории не отдаются всякие Contents и т.п. Ну и на всякий случай : Package: * Pin: origin "httpredir.debian.org" Pin-Priority: -100 -- Stanislav
Re: Devuan (Was: [debian-devel] Обсуждение удаления sysvinit-скриптов из пакетов.)
On Tuesday 13 September 2016 04:21:01 Dmitrii Kashin wrote: > Victor Wagner writes: > > Можно предолжить эту систему проекту devuan или самому дистрибутив > > форкнуть. > > Кстати, вот интересный вопрос: кто-нибудь его уже поставил в качестве > основной системы? > > У меня всё руки не дойдут. На одной из машин я сейчас держу смешанную > систему, но я довыпендривался с репами и, похоже, придётся впервые за 6 > лет систему сносить и с нуля накатывать. Вот думаю: перебраться, что ли, > на devuan полностью, или опять держать смешанную систему debian/devuan? > > Суть в том, что в devuan в пылу выпиливания libsystemd0 много чего > выкинули из репозитория. Не то, чтобы жизненно необходимые вещи, но вот > потеря mpd лично мне не приятна очень. Привык я к нему. > > Поделитесь мнениями, пожалуйста. Стоит ли выделить одну из рабочих машин > под Devuan? Здравствуйте! У меня большая часть поддерживаемых линуксовых машин под Devuan - штук десять серверов, десятка два десктопов с Devuan и Trinity, всякие роутеры, есть даже экзотика на PowerPC. Все работает без особых нареканий. Раньше ставил Debian и переключался на Devuan, с выходом беты ставлю сразу Devuan. Так что однозначно советую. С уважением, Соловьев Юрий
