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
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
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
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-файла - нет.
