Eugene Berdnikov <b...@protva.ru> wrote: > On Fri, Sep 15, 2023 at 10:11:34AM +0300, Andrey Jr. Melnikov wrote: > > Eugene Berdnikov <b...@protva.ru> wrote: > > > и в итоге сделал для себя вывод, что проще поставить на хост systemd > > > чем 100 раз отжиматься... Под systemd оно сразу и shutdown/reboot > > > нормально > > > отрабатывало, и вложенные контейнеры запускало, и ещё чего-то там делало, > > > что под SysV лечилось лишь напильником. > > Хахаха... Ты нашёл замшелую граблю обильно присыпанную пылью веков. Всё дело > > в том, что lxc использует SIGPWR для останова контенйнеров, а в inittab'e от > > SysV-init прописано обработчик "pf::powerwait:/etc/init.d/powerfail start"
> Если такая грабля существовала, это не то, с чем сталкивался я... > Насчёт SIGPWR не знаю, скорее всего он используется, но конечный результат > зависит и от процесса, управляющего контейнером, и от поведения init'а > внутри контейнера. Вот у меня контейнеры с дебианами примерно от 2008 года > (с апдейтами, да), с такими строчками в inittab'e: > # What to do when the power fails/returns. > pf::powerwait:/etc/init.d/powerfail start > pn::powerfailnow:/etc/init.d/powerfail now > po::powerokwait:/etc/init.d/powerfail stop > причём никаких /etc/init.d/power* нет, а системы нормально гасятся и > поднимаются. Под systemd. Так systemd плевать хотел на /etc/initttab. Он им не пользуется. И на SIGPWR тоже, т.к. у Поттеринга на него алергия: -- cut -- My recommendatin: don't bother with SIGPWR. Traditionally on UNIX UPS software sends SIGPWR to PID 1 to initiate some special kind of shutdown operation. But it's very vaguely defined only, and one wonders why a normal shutdown isn't enough here, and why to bounce this off PID 1 with a special UNIX signal even... I am pretty sure that power management software that runs in userspace really shouldn't make use of this anymore. It should just request a normal shutdown. The only reason why one would want to bother with SIGPWR at all is that some really power-related old kernel drivers send SIGPWR to PID 1 too. >From the systemd PoV: this stuff is ugly legacy crap that only exists for historic reasons and was never really well-defined in its behavour. It mostly appears to be a concept that exists only because Linux never had a useful IPC that was accessible from both kernelspace and userspace in a sane way... In systemd, we don't want anything to do with it, but some legacy folks really think it's superduper important. Hence we simply map it to a target unit, and enable users to map it to whatever they want to map it, but don't do anything smart about it at all on our own. I think it would be best of people would just forget about it... Lennart -- cut -- так что, там используется SIGRTMIN+4, потмоу что вот. > Когда я игрался с подобными контейнерами под SysV, там было примерно > такое: по lxc-stop контейнер шустро сворачивается, а потом lxc-stop > висит 2-3 минуты, ожидая какого-то ответа из сокета, и выдаёт > невразумительное сообщение об ошибке. При этом в контейнере ничего > не ломается. Там было 2 проблемы - кривость в использовании io_uring, и ещё какие-то проблемы с управляющим терминалом (точнее с детачингом от него демонов, которые ну очень хотят в него отсылать сообщения). Но меня эта проблема не волнует - контейнеры останавливаются редко, спешки в этом никакой нет. А то, что надо прям сейчас - подхватит другой контейнер, после того, как init убъет VRRP демона. А что он там будет делать дальше - никого уже не волнует. > И много подобных неудобств и граблей было, всех уже не вспомнить... > > Если сегодня под SysV инфраструктура lxc нормально живёт, это замечательно, > но мне надо было вчера, и для этих задач я для себя выбрал systemd. У меня и работает со вчера. Только пришлось немного посмотреть, почему оно так. А верить в магию systemd "просто поставь его" - это не наш метод.
