Есть у кого чего сказать про 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?
В букворме сломана поддержка rsyslog в sysv:Да, у них политика партии - systemd. И эта политика получается из-за gnome и
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 оноЗачем всё так сложно ? Поставь orphan-sysvinit-scripts - оно само тебе
переживать будет.
А можно и по сторонам посмотреть. Есть у кого чего сказать про devuan?Эти тоже со своими тараканами. Почему нельзя было взять udev из дебиана и
Rsyslog переломан в нескольких местах.Если не ошибаюсь, то в последнем (12) Дебьяне rsyslog по умолчанию не ставится и стоит только
Так нынешний udev - это кусок systemd. Его, конечно, можно без самогоА можно и по сторонам посмотреть. Есть у кого чего сказать проЭти тоже со своими тараканами. Почему нельзя было взять udev из
devuan?
дебиана и его использовать? Нет, надо тащить eudev в который
запиливать фичи из udev. Классическое "К соседу в сарай через
Никарагуа".
On 2023-09-07 04:09, Eugene Berdnikov wrote:
Rsyslog переломан в нескольких местах.Если не ошибаюсь, то в последнем (12) Дебьяне rsyslog по умолчанию не
ставится и стоит только системный журнал из systemd...
https://wiki.debian.org/Rsyslog#Deprecation_in_Bookworm
А по поводу rsyslog-rotate, можно проверить, что патч
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031399#24 накладывается и
корректно работает, а потом вежливо, [...]
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 секунды после перезапуска" -- всё равно бывали
случаи, когда процесс не запускался. Автоподъём по крону эту проблему
решает, но нужно понимать, что иногда система живёт без сислога.
Единственная известная мне альтернатива rsyslog-у, умеющая делить логиМожно поподробнее про syslog-ng ? используем syslog-ng на большом
по шаблонам/регуляркам, это syslog-ng. К сожалению, сейчас его автора,
что называется, понесло... А раньше syslog-ng иногда подвисал из-за
какой-то баги. При этом он переставал принимать пакеты, и подвисала
практически вся система, ибо в юниксах код syslog(3) традиционно
блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все
материалы для багрепорта, но времени оформить его не хватило, пришлось
просто оставить syslog-ng. Альтернатива в виде rsyslog'а хоть с костылями
и через пень-колоду, но всё-таки работает и не убивает всю систему.
Andrey Jr. Melnikov уже написал, что скрипт положили, но в пакет[...]
orphan-sysvinit-scripts. Правда туда положили и /usr/lib/rsyslog/rsyslog-rotate.
Но там не написано, что выполнить задачу скрипта /etc/init.d/rsyslog
не очень просто, потому что rsyslogd при рестарте запускается через раз.
Мои попытки сделать в скрипте цикл и на каждой итерации проверять,
запустился rsyslogd или нет, не привели к успеху даже в варианте
"5 итераций и ожидание 3 секунды после перезапуска" -- всё равно бывали
случаи, когда процесс не запускался. Автоподъём по крону эту проблему
решает, но нужно понимать, что иногда система живёт без сислога.
А оригинальный init скрипт с этой задачей не справлялся что-ли? Какие-то
сложности с сетевыми сокетами или что-то другое?
07.09.2023 15:09, Eugene Berdnikov пишет:[...]
[...]что называется, понесло... А раньше syslog-ng иногда подвисал из-за
какой-то баги. При этом он переставал принимать пакеты, и подвисала
практически вся система, ибо в юниксах код syslog(3) традиционно
блокирующийся, и в линуксе GNU libc, там так же. Я даже собрал все
материалы для багрепорта, но времени оформить его не хватило, пришлось
Можно поподробнее про syslog-ng ? используем syslog-ng на большом количестве
серверов со стретча до булзая, в разных позах - никаких проблем не замечали
А у тебя случаем контейнеров на машинке не крутится? А то смотри,
start-stop-daemon у нас тупенький, он про отдельные неймспесы ничего не
знает. Поэтому, когда у тебя запущенно несколько экземпляров чего либо в
различных контейнерах - start-stop-daemon на host-машине ведет себя весма
оригинально - то сигнал не в тот процесс пришлёт, то узрит живущий демон в
контенйнере и откажется запускать его-же на хосте. Из-за этого, приходтся
весь пакадж с dpkg пересобирать. Хотя, надо наверное сделать отдельный и
через dpkg-divert подсовывать нужный start-stop-daemon.
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
с тех пор обновлялся, в том числе совсем недавно:
On Thu, Sep 14, 2023 at 12:21:03PM +0300, Andrey Jr. Melnikov wrote:У меня везде стоит SysV-init где контейнеры. И ничего - граблей не наблюдаю.
А у тебя случаем контейнеров на машинке не крутится? А то смотри,
start-stop-daemon у нас тупенький, он про отдельные неймспесы ничего не
знает. Поэтому, когда у тебя запущенно несколько экземпляров чего либо в
различных контейнерах - start-stop-daemon на host-машине ведет себя весма
оригинально - то сигнал не в тот процесс пришлёт, то узрит живущий демон в
контенйнере и откажется запускать его-же на хосте. Из-за этого, приходтся
весь пакадж с dpkg пересобирать. Хотя, надо наверное сделать отдельный и
через dpkg-divert подсовывать нужный start-stop-daemon.
У меня везде, где есть контейнеры, стоит система инициализации systemd.
Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно
запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный
бег по граблям).
Но я писал про сислоги в контексте физических машин и контейнеровВопрос не во вложенности, а имеено в том, что на физическом хосте
без вложенности, где start-stop-daemon ошибиться не может.
Eugene Berdnikov <bd4@protva.ru> wrote:
, , systemd.SysV-init . - . systemd - , .
lxc, , SysV-init (, ,
lxc sysv, ,
).
, , start-stop-daemon . :
On Thu, Sep 14, 2023 at 02:26:07PM +0300, Andrey Jr. Melnikov wrote:Хахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело
Eugene Berdnikov <bd4@protva.ru> wrote:
У меня везде, где есть контейнеры, стоит система инициализации systemd.У меня везде стоит SysV-init где контейнеры. И ничего - граблей не наблюдаю.
Потому что lxc, например, под SysV-init не жилец (да, я знаю, что можно
запускать контейнеры lxc под sysv, но это будет не работа, а бесконечный
бег по граблям).
И даже контейненры с systemd внутри - тоже работают, хотя раньше это изделие
не могло там стартануть нормально.
Ну так 1. я про то, что было раньше, несколько лет назад, 2. контейнеры
они разные бывают. Несколько лет назад я пытался завести lxc-шные,
начитался разных wiki на тему "как заставить это работать под SysV",
и в итоге сделал для себя вывод, что проще поставить на хост systemd
чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально
отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало,
что под SysV лечилось лишь напильником.
Тенденция такова, что как только отстал от мейстрима, так проблемы растут,Эмм, за последние 15 лет не выпускалось процессоров без поддержки x64.
отнимая всё больше времени и сил... Вон, формально для i686 до сих пор
собирают mplayer и chrome. Однако на тех процах, которые были во времена
мейнстрима i686, как правило, не было SSSE3, которые эти изделия хотят.SSE3, как впрочем и всякие AVX512 - сильно перероценён и больше представляет
И ведь можно было бы обойтись, просто работать медленнее, но нет, кодерам
неинтересна поддержка "убогих" процов, им проще тупо вернуть статус-код.
Ну а если у меня современный проц, зачем мне гонять на нём 32-битнуюЗакапывать надо такие конфигурации, как стюардессу.
базовую систему? Я 64 заведу, а всякие ископаемые конфигурации, которые
слишком дорого переделывать, загоню в 32-битные виртуалки/контейнеры.
И так оно везде, к сожалению. В том числе в виртуализации, всех видов.Контенер с SysV живёт где угодно, ему тупо не надо, как systemd -
Вопрос не во вложенности, а имеено в том, что на физическом хосте
start-stop-daemon путается в запущенном. Следи за руками:
Да это понятно. Я про то, что в контейнере start-stop-daemon не путается,
если там других (вложенных) контейнеров нет. Потому как в контейнере
ему лишь свои и дочерние процессы видны. Поэтому под systemd контейнер
с инициализаций SysV нормально живёт.
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 $? почему оно должно путаться - я вообще не понимаю
Eugene Berdnikov <bd4@protva.ru> wrote:
и в итоге сделал для себя вывод, что проще поставить на хост systemdХахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело
чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot нормально
отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало,
что под SysV лечилось лишь напильником.
в том, что lxc использует SIGPWR для останова контенйнеров, а в inittab'e от
SysV-init прописано обработчик "pf::powerwait:/etc/init.d/powerfail start"
Вопрос не во вложенности, а имеено в том, что на физическом хосте
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
On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote:Так systemd плевать хотел на /etc/initttab. Он им не пользуется. И на SIGPWR
Eugene Berdnikov <bd4@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.
From the systemd PoV: this stuff is ugly legacy crap that only existsfor historic reasons and was never really well-defined in its
Когда я игрался с подобными контейнерами под SysV, там было примерноТам было 2 проблемы - кривость в использовании io_uring, и ещё какие-то
такое: по lxc-stop контейнер шустро сворачивается, а потом lxc-stop
висит 2-3 минуты, ожидая какого-то ответа из сокета, и выдаёт
невразумительное сообщение об ошибке. При этом в контейнере ничего
не ломается.
И много подобных неудобств и граблей было, всех уже не вспомнить...У меня и работает со вчера. Только пришлось немного посмотреть, почему оно
Если сегодня под SysV инфраструктура lxc нормально живёт, это замечательно,
но мне надо было вчера, и для этих задач я для себя выбрал systemd.
Eugene Berdnikov <bd4@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 /etc/initttab. .
. systemd.
SIGPWR , .. :
On Fri, Sep 15, 2023 at 05:03:50PM +0300, Andrey Jr. Melnikov wrote:
Eugene Berdnikov <bd4@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
В верхней строчке написано: "дебианы от 2008 года". Ясное дело, там SysV,причём никаких /etc/init.d/power* нет, а системы нормально гасятся иТак systemd плевать хотел на /etc/initttab. Он им не пользуется.
поднимаются. Под systemd.
в контейнере, а не снаружи. Ты бы хоть читал то, на что отвечаешь...
Увы, Лёня ещё тот чудак на другую букву. И ничего нового (кроме сказок о томИ на SIGPWR тоже, т.к. у Поттеринга на него алергия:
Согласен с Поттерингом: да, все варианты проблем с электропитанием в один
лишь SIGPWR запихнуть невозможно, потому и сакрального смысла в нём нет.
Трахаться с ним или сразу закопать -- решать Поттерингу: он свои силы
тратит на движение прогресса, а мы пользуемся результатом.
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
вроде создает, так что это влиять не должно.
Я бы понял, если бы он сделал 3
сигнала SIGPWR для информирования о том, что питание пропало, SIGRTMIN+x1
для информирования о том, что питание появилось обратно и SIGRTMIN+x2 - для
emergency power shutdown - был бы разговор о прогрессе и удобстве.
On Tue, Sep 19, 2023 at 10:02:00AM +0300, Andrey Jr. Melnikov wrote:
Max Nikulin wrote:
контейнер выделяется по pidns. У меня, конечно systemd, но pidns же lxc
вроде создает, так что это влиять не должно.
Нет, не проблема. Проблема написать баг-репорт и донести его нужность до
маинтайнеров, у которых теперь есть на всё одна отмазка "sysvinit устарел,
под systemd всё работает (C)".
Писать лучше патч, с ним багрепорт имеет намного больше шансов на успех.
Хотя и это не всегда помогает...
On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:init должен запускать просто нужный target/script/runlevel/чётамещё.
Я бы понял, если бы он сделал 3
сигнала SIGPWR для информирования о том, что питание пропало, SIGRTMIN+x1
для информирования о том, что питание появилось обратно и SIGRTMIN+x2 - для
emergency power shutdown - был бы разговор о прогрессе и удобстве.
Лично у меня сомнения, что этим должен заниматься именно init.
Вроде задача для пользовательского процесса, который сходит спросит, сколькоДиск сам запаркуется. Он тупо ближе к акселерометру и быстрее.
заряда осталось у аккумулятора, а потом уже будет решать, на сколько
спешно надо останавливать систему. В ноутбуках акселерометры, по которым
можно парковать головки жесткого диска при падении, доступны просто как
файлы в /sys.
Реакция на событие нужна за доли секунды, а init для этого не обязателен.Он для этого и не нужен. init и обработка realtime сигналов - это из области
Не убедительно, что сообщать о пропадании/восстановлении питания надоДля ноутбука - может и не убедительно, а для удалённого UPS, который где-то
именно разными сигналами.
Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало
питание - посылает сигнал, появилось - посылает сигнал (ну тут всё
стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть
понимание - init дернул power-loss скриптик, в котором уже можно оценить
масштаб проблемы, остановить нужное и принять решение - ждём восстановления
или отключаемся. Или init дернул power-restored - когда поднимаем
остановленное или в зависимости от - тупо перезагружаемся.
Нет, через один SIGPWR это тоже всё решалось и решается, только вот скриптик
будет разляпистее.
On 24/09/2023 01:52, Andrey Jr. Melnikov wrote:е между ними init и сигналы?
Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало
питание - посылает сигнал, появилось - посылает сигнал (ну тут всё
стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть
понимание - init дернул power-loss скриптик, в котором уже можно оценить
масштаб проблемы, остановить нужное и принять решение - ждём восстановления
или отключаемся. Или init дернул power-restored - когда поднимаем
остановленное или в зависимости от - тупо перезагружаемся.
Нет, через один SIGPWR то тоже всё решалось и решается, только вот скриптик
будет разляпистее.
Я все еще сомневаюсь, нужно ли здесь завязываться на init.
Почему обычный демон не может сам запускать, в зависимости от ситуации, либо power-loss, либо power-restored скрипты? В чем польза того, что в промежутк
Единственное преимущество от SIGPWR, которое я вижу, - то зафиксированный API. Недостаток - API очень ограниченный. Даже если добавить еще сигнаов, то становится не очевидно, какому сигналу соответствует событие. /etc/inittab как известная точка конфигурации для меня не убедительное дос
Если скрипты запускаются напрямую демоном, который слушает SNMP, то событий может быть несколько и со вполне нормальными именами. Главная поблема - договориться о именах скриптов и их параметрах. Иначе будет головная боль с тем, что у каждого производителя UPS они будут свои и не
On 24/09/2023 01:52, Andrey Jr. Melnikov wrote:Поздравляю, ты придумал init в софтине для UPS. Теперь все остальные должны
Вот и смотри - есть демон, который мониторит сосотяние UPS'a - пропало
питание - посылает сигнал, появилось - посылает сигнал (ну тут всё
стандартно, так уже лет 40 делают). Просто удобнее, когда у тебя есть
понимание - init дернул power-loss скриптик, в котором уже можно оценить
масштаб проблемы, остановить нужное и принять решение - ждём восстановления
или отключаемся. Или init дернул power-restored - когда поднимаем
остановленное или в зависимости от - тупо перезагружаемся.
Нет, через один SIGPWR это тоже всё решалось и решается, только вот скриптик
будет разляпистее.
Я все еще сомневаюсь, нужно ли здесь завязываться на init.
Почему обычный демон не может сам запускать, в зависимости от ситуации,
либо power-loss, либо power-restored скрипты? В чем польза того, что в
промежутке между ними init и сигналы?
Единственное преимущество от SIGPWR, которое я вижу, - этоПриемущество - то, что интерфейс сискола signal(..) известен всем и каждому,
зафиксированный API. Недостаток - API очень ограниченный.Недостаток тут только один - невозможно выборочно остановить/запустить
Даже если добавить еще сигналов, то становится не очевидно, какому сигналут.е. прочитать в man'e про конфигурацию используемого init'a - это не модно?
соответствует событие. /etc/inittab как известная точка конфигурации для
меня не убедительное достоинство, не SysV init может использовать другойОпять-же - ты придумал init.
файл, чтобы назначать обработчики.
Если скрипты запускаются напрямую демоном, который слушает SNMP, то
событий может быть несколько и со вполне нормальными именами. Главная
проблема - договориться о именах скриптов и их параметрах. Иначе будет
головная боль с тем, что у каждого производителя UPS они будут свои и не
очень совместимые между собой. Да, договариваться сложно, уходящий
корнями в прошлое SIGPWR, выглядит более знакомым и поэтому привлекательным.
Поздравляю, ты придумал init в софтине для UPS. Теперь все остальные должны
знать про неё - а она должна знать про всё остальное.
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.
On 24/09/2023 20:29, Andrey Jr. Melnikov wrote:Вот SIGPWR - это и есть изменение runlevel'а. Только сигналом - а не telinit
Поздравляю, ты придумал 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 и скриптам.
On 24/09/2023 20:29, Andrey Jr. Melnikov wrote:
Поздравляю, ты придумал init в софтине для UPS. Теперь все
остальные должны знать про неё - а она должна знать про всё
остальное.
Нет. Я увидел сожаление, что такой хороший интерфейс, как SIGPWR не
расширяют. Мне кажется это странным, если можно запускать в
Для того чтобы демон ИБП мог потушить весь сервер ему нужны
соответствующие права, а он может быть запущен с понижением привилегий.
И послать сигнал SIGPWR иниту он может, а вот уже запустить
/sbin/shutdown — рожей не вышел.
В Mon, 25 Sep 2023 00:04:03 +0700
Max Nikulin пишет:
Нет. Я увидел сожаление, что такой хороший интерфейс, как 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 сигнала SIGPWR для информирования о том,
что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
разговор о прогрессе и удобстве.
On 24/09/2023 17:00, Михаил Касаджиков wrote:EPERM. Иначе любой взбесившийся php скрипт на shared hosting мог бы слать сигналы init. Или считается, что оставить демону UPS CAP_KILL то приемлемое решение
Для того чтобы демон ИБП мог потушить весь сервер ему нужны
соответствующие права, а он может быть запущен с понижением привилегий.
И послать сигнал SIGPWR иниту он может, а вот уже запустить
/sbin/shutdown — рожей не вышел.
Не могу сообразить, что именно я пропустил. Послать сигнал init тоже может не любой процесс. Вызвать kill может любой, но в ответ может получить
On 25/09/2023 16:42, Victor Wagner wrote:Даа, читал ты его явно по диагонали. Сейчас POWEROK событие выглядит так -
В 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
Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся эта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)Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей
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.
точки зрения, не лучше.
On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:Увы, в systemd тоже этого не сделали.
Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том,
что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
разговор о прогрессе и удобстве.
Это про systemd было.
Ну отправит иниту кто угодно сигнал SIGPWR, запустит инит
соответствующий скрипт, тот, в свою очередь увидит что нет причин для
беспокойства и ничего не сделает. Опять же, в те времена, когда всё это
придумывали, не было shared hosting в его нынешнем виде. Другое дело что
всю эту систему до ума не довели, вот и имеем то что имеем — ПО для ИБП
предпочитает всё делать самостоятельно.
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... :)
В чём была проблема -- мне тогда
докопаться не удалось (уже не помню, почему, кажется, под strace эта
зараза всегда успешно работала, а без strace процесс исчезал, не оставляя
ни корки, ни других следов). Возможно, багу пофиксили, поскольку ryslog
с тех пор обновлялся, в том числе совсем недавно:
2023-08-19 21:42:26 upgrade rsyslog:i386 8.2306.0-2 8.2308.0-1
--
Eugene Berdnikov
Max Nikulin wrote:
https://manpages.debian.org/bookworm/sysvinit-core/init.8.en.html#CHANGING_RUNLEVELSДаа, читал ты его явно по диагонали.
я перестал понимать, куда его дальше-то расширять? Вроде наоборот хотят
сузить, выкинув /etc/powerstatus, по которому определяется, какой из 3
скриптов запускать по SIGPWR
Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся этаL(OW)Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей
The power is failing and the UPS has a low battery. Execute the
powerfailnow entries.
точки зрения, не лучше.
пляска вокруг файликов с сигналами и FIFO?
On 19/09/2023 14:00, Andrey Jr. Melnikov wrote:
Я бы понял, если бы он сделал 3 сигнала SIGPWR для информирования о том,
что питание пропало, SIGRTMIN+x1 для информирования о том, что питание
появилось обратно и SIGRTMIN+x2 - для emergency power shutdown - был бы
разговор о прогрессе и удобстве.
Это про systemd было.Увы, в systemd тоже этого не сделали.
Да, задизайнить
SIGRTMIN+4 в poweroff и SIGRTMIN+14 в immediate poweroff - смог
On Tue, Sep 12, 2023 at 10:55:46PM +0300, Eugene Berdnikov wrote:
Но не тут-то было: сегодня 4 раза подряд rsyslogd не запустился... :)
На том же хосте, где 2 недели назад проверялся orphan-sysvinit-scripts.
В чём была проблема -- мне тогда
докопаться не удалось (уже не помню, почему, кажется, под strace эта
зараза всегда успешно работала, а без strace процесс исчезал, не оставляя
ни корки, ни других следов).
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).
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, что не особенно принципиально (из разряда мелочь,
но приятно).
Т.е. с твоей точки зраения один signal(1, SIGRTMIN+x) хуже чем вся этаL(OW)Я не в восторге от такого решения, но и предлагавшиеся 3 сигнала, с моей
The power is failing and the UPS has a low battery. Execute the
powerfailnow entries.
точки зрения, не лучше.
пляска вокруг файликов с сигналами и FIFO?
Я думаю, мы ни до чего не договоримся, да и не важно, ведь ни на что это
не повлияет.
Да, у меня прямо противоположное мнение о том, какой интерфейс лучшеКогда они его выбирали - про SIGRTMIN ещё даже никто и не думал. SIGRTMIN
подходит. Перенумеровать все возможные события - затея гиблая, люди в
них начнут путаться. Надо ведь еще и имена им дать. Поэтому я против 3-х
сигналов.
Я думаю, что когда люди выбрали один SIGPWR + /etc/powerstatus, они
рассматривали 3 сигнала и остановились на варианте, который сейчас
выглядит несколько вычурным.
Послать-то сигнал может и просто, а вот правильно поймать уже некотороеВот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы -
искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я
сигналы не люблю.
С сокетами проще. Если есть утилита и библиотека, которые могут слатьПроще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать
нужные сообщения, и процесс их может правильно обработать, то это лучше,
чем сигналы. Мне такой вариант нравится больше.
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()).
но)и он перед кзитом выполняет такой код:
[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().
Max Nikulin <manikulin@gmail.com> wrote:
Послать-то сигнал может и просто, а вот правильно поймать уже некотороеВот и не надо перекладывать свои "люблю-нелюблю" на всех. Сигналы -
искусство. Чинить обработчики сигналов - трудоемкий процесс. За это я
сигналы не люблю.
хорошее, правильное асинхронное средство донести до процесса необходимую
информацию.
С сокетами проще. Если есть утилита и библиотека, которые могут слатьПроще? Создать сокет, открыть сокет, крутить select() в цикле, обрабатывать
нужные сообщения, и процесс их может правильно обработать, то это лучше,
чем сигналы. Мне такой вариант нравится больше.
ошибки, прочитать сокет (если прочитается), закрыть сокет.. и это все вместо
одного signal handler?
On Thu, Sep 28, 2023 at 11:52:49PM +0300, Andrey Jr. Melnikov wrote:
Это явно результат вызова openlog() где-то внутри syslog().
Я догадываюсь, но syslogd, вызывающий openlog(), это форменная шиза...
Ты не считаешь, что автора такого изделия нужно везти в психушку? :)
пт, 29 сент. 2023 г. в 12:37, Eugene Berdnikov <[1]bd4@protva.ru>:
> Потому как любое
> действие, затрагивающее libc, грозит разносом стэка, и вообще во время
> обработки сигнала сплошь минные поля. А когда из сигхэндлера вернулся,
> нужно как-то мониторить тот факт, что тебе пришёл сигнал, т.е. рядом
> с poll/select будет ещё вычитывание той переменной, с флагом.
Это тоже не совсем так. Во-первых, man 7 signal-safety содержит список
async signal safe функций, которые можно дергать из обработчика сигнала.
Во-вторых, трюк с глобальным флагом - он так себе, обычно либо в пайп
писали из обработчика сигнала, который ждали на том самом select'е (и
On Thu, Sep 28, 2023 at 05:32:35PM +0700, Max Nikulin wrote:
Останавливается перед этим нормально?
Ммм... не знаю. Он при остановке что-то странное делает.
# 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) и ура, с первого раза поймали.
Сигналы не накапливаются в очередь.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 99:56:04 |
| Calls: | 6,850 |
| Calls today: | 1 |
| Files: | 12,354 |
| Messages: | 5,415,227 |