Debian и Devuan объединили усилия ради sysvinit

    Несколько дней назад вышла в свет с опережением графика очередная версия классической Unix/Linux системы инициализации sysvinit 2.92. Предыдущий выпуск 2.91 вышел чуть больше месяца назад.


    devu


    Что же примечательного в выходе минорной версии старинной системы инициализации (СИ), от которой отказались почти все современные дистрибутивы Linux, и какая от этого радость сообществу сторонников открытого кода и пользователям Debian Linux?


    Интересен же данный эпизод тем, что релиз состоялся совместными усилиями двух антагонистических групп разработчиков Debian и Devuan, которые 4 г. тому назад раскололись из-за ситуации вокруг systemd. Но давайте по порядку.


    Тройное голосование по systemd


    За несколько месяцев до выхода Debian Jessie лидеры проекта встали перед необходимостью определиться с системой инициализации. В то время systemd уже набирал популярность и был одним из главных претендентов. Всего в забеге участвовали четыре СИ.


    • systemd;
    • upstart;
    • openrc;
    • sysvinit.

    В голосовании также имелся выбор «требуется дальнейшее обсуждение».


    Результаты первого тура показали равновесие между upstart и systemd, каждый из них получил по 4 голоса. Для принятия решения необходимо было соотношение голосов 2:1.


    Через 2 недели после этого в начале февраля 2014 г. прошел второй тур, в котором ничего нового по сути не произошло. Голоса разделились в той же пропорции и было принято решение о дальнейших дебатах.


    В пользу systemd проголосовали:


    • Bdale Garbee — председатель Технического Комитета;
    • Don Armstrong;
    • Keith Packard — гуру иксов, в данный момент работает в Valve;
    • Russ Albery.

    За upstart проголосовали:


    • Colin Watson;
    • Steve Langasek;
    • Ian Jackson;
    • Andreas Barth.

    И в третий раз проголосовал ТК, значительно упростив регламент и постановку вопроса. Исключив из повестки все вторичные вопросы и снизив порог принятия решения до простого большинства, комитет с третьего захода проголосовал в пользу systemd


    Нет, никто из сторонников upstart не переметнулся в противоположный лагерь, итог голосования решил дополнительный голос председателя Технического Комитета Бидейла Гарби, и с перевесом всего в один голос вопрос СИ для Debian Linux был решен при прежнем балансе мнений 4:4.


    Линус бреет Бидейла Гарби на LinuxConf 2009 г.


    shave


    Итог голосования вызвал резкое чувство горечи, разочарования и несправедливости у противников systemd. В списках рассылки Debian страсти разыгрались не на шутку.


    Ian Jackson призвал Бидейла Гарби подать в отставку с поста председателя ТК. Затем выпустив пар, решил на время отойти от участия в делах ТК.


    Через пару дней 11 февраля стало ясно, что решение для Debian Linux окончательно принято и в обозримым будущем основной системой инициализации дистрибутива будет systemd.


    Devuan


    Разработчики дистрибутива Debian Linux, несогласные с таким положением дел, недолго горевали и за полгода до выхода той самой 8-й версии уже на основе systvinit создали свой форк и назвали его Devuan, отталкиваясь от словосочетания Dev one.


    Изюминкой дистрибутива и его главным отличие от материнской ОС стало то, из-за чего затеяли весь сыр-бор. Devuan Linux выбрал sysvinit в качестве СИ. В целом рождение развитие дистрибутива, было встречено с большим энтузиазмом в среде пользователей Linux, не исключая русскоязычной его части.


    В июне вышла уже вторая версия дистрибутива на пакетной базе последней версии своего предка — Debian Stretch. Помимо sysvinit в качестве СИ можно также выбрать openrc.


    Попробуем разобраться из-за чего произошел такой раскол в среде разработчиков Debian, да и в целом среди большого количества пользователей различных вариаций ОС Linux. Ведь и раньше бывали трудные решения и опасные повороты в истории развития GNU/Linux: GPLv3 или нет, UEFI SecureBoot и пр. Почему же в этот раз все слетели с катушек?


    Споры вокруг systemd


    Если свести суть всех споров к одному тезису, то можно сказать, что systemd подразумевает размен наиболее полноценного управления инициализацией системы и ее службами на тотальный отказ от философии Unix.


    Причем первое яростно оспаривают противники systemd, но второе никто не оспаривает. Не все согласны с тем, что systemd делает жизнь админа проще, но мало кто может оспорить то, что systemd и Unix Way это две крайности.


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

    Откуда возникла потребность в такой всеобъемлющей системе управления инициализацией ОС и ее процессами? Я не верю в теории заговора и поэтому полагаю, что причины были в недостатках sysvinit и прочих СИ.


    Созданная в 1983 г. sysvinit не умела решать ряд важных задач, таких как:


    • параллельный запуск процессов;
    • обнаружение съемных носителей;
    • активизация сервисов на основе сокетов;
    • надежно контролировать зависимости между различными процессами и службами;
    • раннее логирование событий через /dev/log.

    Все эти и многие другие неудобства были наконец-то решены в systemd. Стандартизация файлов конфигурации, унификация синтаксиса и управление зависимостями служб на основе cgroups предположительно позволили вендорам коммерческих дистрибутивов Linux облегчить жизнь админам и снизить затраты управление серверным парком.


    Но какова была цена? По какому-то странному дизайну детище Леннарта Поттеринга прошло путь от обычной СИ до «набора строительных блоков для Линукс системы». Цитата с главной страницы проекта. Эдакое государство в государстве, управляющее подключением устройств, точек входа файловых систем, сетевыми соединениями, системной службой времени, пользовательскими сеансами, системным журналами и пр.


    Одновременно с этим многие разработчики DE, в особенности Gnome, стали привязывать элементы графического окружения к systemd:


    • управление питанием;
    • управление пользовательскими сеансами;
    • просмотр журнала;
    • если захлопнуть экран ноутбука, то события не будут обработаны;
    • Wayland.

    Все это не взлетит в Gnome без специальных патчей, если выбрать иную СИ кроме systemd.


    Причина же такого положения дел в том, что слишком сложно поддерживать два варианта для множества наборов программ: один с systemd, а другой — без. В результате создается такая ситуация, когда в дистрибутиве Linux нет возможности выбрать другую СИ.


    Облако тэгов ключевых слов вокруг systemd в Твиттере.


    systemd


    Ну хорошо, нет возможности выбора СИ, так ли это важно на самом деле? Не думаю, что меня сильно огорчит, если не будет возможности выбора загрузчика ОС, или клиента DHCP.


    Как оказывается многих пользователей systemd раздражает уйма вещей. Раннее и полное логирование системных событий с самого момента запуска это конечно хорошо, но как можно себе представить Linux систему с бинарными лог-файлами?


    Леннарт Поттеринг может быть хорошим программистом, но стиль его общения и реакция на обнаруженные дефекты, на критику — ниже всякой критики. Вот его реакция на дефект 5644.


    Сам дефект.


    # mkdir -p /foo/dir{1,2}
    # touch /foo/.bar{1,2}
    # cat /etc/tmpfiles.d/test.conf
    R! /foo/.* - - - - -
    Reboot.

    Комментарий Леннарта Поттеринга.


    I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?.

    Это не единичный случай, такой стиль общения снискал ему недобрую славу с среде гиков. И это только часть претензий к systemd и его автору. В силу своего размаха, масштаба и сложности система может быть хрупкой в качестве СИ — своей основной функции.


    Пусть так, systemd превосходит все основные СИ по своим возможностям, однако все равно остается вопрос. Почему обычные админы localhost-а не имеют возможности выбрать для Debian Linux и других дистрибутивов, более простую в эксплуатации и отладке СИ? Ведь далеко не каждому нужен параллельный запуск процессов и управление квотами.


    Мое понимание ситуации с systemd в том, что более совершенную, но вместе с тем для многих неоправданно сложную и непрозрачную СИ навязали тем, кому это было нужно и тем кому нет. Многим пользователям Linux это не понравилось и они стали сетовать на то, что теперь Linux стал как Windows, но только с открытым исходным кодом.


    DnD совместно работают над sysvinit


    И теперь наконец-то хорошие новости! В последнее время наметились подвижки между группами разработчиков СИ Debian и Devuan. Решено объединить усилия по нескольким направлениям.


    • Поддерживать на плаву sysvinit для тех, кто готов использовать Debian Linux со всеми ограничениями, в т. ч. без графического окружения. Требуется помощь Devuan-цев в подготовке 10-й версии Debian, получившей название Buster.
    • В результате подобного «перекрестного опыления» Debian-щики помогли коллегам из Devuan в подготовке выпуска sysvinit 2.92. Благодаря этому сроки сократились и выпуск состоялся до НГ, как было сказано в начале поста.

    Если здравый смысл возобладает то обе группы разработчиков смогут поставить и реализовать более актуальные для всех пользователей Debian/Devuan цели — добиться полноценной поддержки нескольких СИ для Devuan Linux: openrc, s6, runit, nosh и т. д. Так же и Debian Linux полноценная поддержка хотя бы одной отличной от systemd СИ несомненно пошла бы на пользу.


    P. S. В Амсдердаме 5-7 апреля 2019 г. пройдет первая конференция Devuan Linux.


    Дополнительное чтение


    Поделиться публикацией

    Похожие публикации

    Комментарии 114
      +12
      Может быть конечно systemd и монстр, но unit-файлы это удобно, и возвращаться на громоздкость sysvinit как-то совсем не хочется.
        +7
        Поддержу. А upstart редкое… уродство. Я пробовал воевать с upstart и просто счастлив, что убунт овцы одумались и выпилили его в 16.04 в пользу systemd.
          –3
          А я вот типичный админ локалхоста, и с переходом на systemd у меня появилось столько проблем, что я бы с радостью засунул эту systemd в… короче, далеко.
          До сих пор не смог до конца разобраться, почему некоторые сервисы не стартуют, правила iptables то работают, то нет, saned вот вдруг отвалился, приходится сканировать через scanimage.
          До этого 10 лет все работало, пережило кучу апгрейдов, а тут вдруг перестало…
            0
            А мне upstart вполне зашёл, нет того бардака c init.d, rcX.d, писать стартовые скрипты просто и работают они надёжно. В sysvinit приходилось мучаться с эклектичным синтаксисом баша и велосипедами на простые действия. Но между сисвинит и системгэ я выбираю первое :)
          +2
          Название статьи сделайте нормальное. Я бы ее провел с намного большим удовольствием, если понял сразу о чём идёт речь, а то «Debian» в качестве заголовко — ну, вообще верх минимализма
            +1

            Уже подправил, это была неудачная попытка использовать эмодзи символы в заголовке. Предполагалось название — Debian

            • НЛО прилетело и опубликовало эту надпись здесь
              • НЛО прилетело и опубликовало эту надпись здесь
            +4
            Почему обычные админы localhost-а не имеют возможности

            Но есть же и плюсы, опыт управления localhost можно использовать
            для управления любой машиной с Linux и даже не нужно разбираться что там
            за дистрибутив.

              –3
              systemd один, но вот набор костылей unit-файлов в каждом дистрибутиве свой (не то, чтобы они прямо кардинально различались от дистрибутива к дистрибутиву, но достаточно, чтобы ваше утверждение было преувеличением)
                +2
                Лично меня, как конечного пользователя, раздражают баги systemd. При этом меня совершенно не волнуют его фичи.
                  +5

                  Уточните, пожалуйста, какие баги раздражают.
                  И был ли открыт по ним issue до вас или вами?

                    0
                    И последнего: подключаете sata hdd на внутренний разъём (например для диагностики), запускаете систему, делаете то, что хотели сделать, завершаете работу, отключаете hdd, включаете систему… а она не включается, потому что systemd запомнил guid файловой системы и не теперь не может его примонтировать.

                    Проблема известная и распространённая, последний раз когда я её смотрел она де факто была «won't fix».

                    У меня возникают вопросы:
                    — Нафига systemd вообще запомил guid ничего у меня не спрашивая?
                    — Почему невозможность примотнировать диск — фатальная ошибка?

                    Вообще, systemd как-то излишне похож на Nero Burning ROM и ASDSee последних версий перед тем как они канули в забвение.
                      +1
                      Вы какую-то ерунду описываете. GUID'ы есть не у файловой системы, а у разделов в GPT, и их не надо «запоминать», потому что они являются магическими константами, указывающими на тип содержимого. systemd точно не занимается вопросами выбора типа раздела на устройстве, так что либо у вас неправильная диагностика проблемы, либо вы не те слова используете для её описания.
                        0
                        Я столкнулся с этой проблемой ~год назад, деталей я уже не помню. Linux на данный момент не является одной из тех os, которые я сейчас активно использую.

                        Про guid раздела вы правы. Запоминать их не надо, но systemd зачем-то это делает. Текст сообщения был вроде бы как «failed to determine partition table type» Лечением проблемы, соответственно, было найти файл со списком разделов и удалить лишнюю запись (и это были не команды для mount, а какой-то кастомный формат)

                        Я могу попробовать воспроизвести эту ошибку, если вы настаиваете.

                          0
                            +1
                            GUID'ы файловых систем, разумеется, надо запоминать. 0FC63DAF-8483-4772-8E79-3D69D8477DE4 — linux filesystem data, CAFECAFE-9B03-4F30-B4C6-B4B80CEFF106 — ceph block data, etc. Но их не запоминают динамически, они где-то хардкожены в коде, и это в соответствии со спецификациями.

                            Воспроизведите, давайте посмотрим, что там происходит. Сколько я дисков не переподтыкал, ничего такого не наблюдал. Ни в бареметалле (и ноутбуках), ни в виртуализированной среде.
                            0
                            Если точнее, то у каждого раздела в GPT есть два гуида, первый является константой и обозначает тип раздела, а второй является случайным идентификатором. Вот второй-то как раз и запоминают.
                              0
                              Первый раз слышу про «два гуида в gpt». Есть guid, указывающий на тип раздела (аналог байтика «тип» в MBR), и есть uuid раздела.
                                +3

                                guid и uuid — это синонимы


                                Согласно спецификации UEFI, в GPT Partition Entry есть PartitionTypeGUID и UniquePartitionGUID

                            0

                            То, что вы описали, никак не имеет отношения к systemd.
                            Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
                            устанавливает дефолтным загрузчиком Windows.

                              0
                              Нет, это не проблема с загрузчиком, так как ядро успешно грузилось. (OpenSuSE в моём случае). Решение на тот момент было успешно нагуглено и применено, просто деталей я уже не помню.
                                +2

                                Собрав по кусочкам информацию от вас. Я пришёл выводу..


                                В данном случае systemd пытался задействовать механизм "The Discoverable Partitions Specification", для автоматического определения разделов.
                                И вот почему:


                                The OS can discover and mount the necessary file systems with a non-existing or incomplete /etc/fstab file and without the root= kernel command line option.

                                Итог: /etc/fstab нет или не полный, опция ядра root= не указана, разделы по спецификации вы явно не настраивали. Но systemd как всегда крайний.

                                  0
                                  Подопытная операционка:
                                  Linux 3.16.7-53-desktop
                                  openSUSE 13.2 (Harlequin) (x86_64)

                                  Опция root= действительно не указанна, но fstab на месте. .mount-файлов в /etc/systemd нет
                                  Разделы вручную я не настраивал потому, что либо за меня это делал инсталлер, либо я это делал через интерфейс Yast'а.

                                  А крайний systemd именно потому, что отвечает за монтирование разделов при загрузке.
                                    0
                                    Опция root= действительно не указанна, но fstab на месте.

                                    Курица или яйцо?

                            0
                            Как знатока багов системдэ, спрошу вас да и просто всех кто знает: как сделать надёжный маунт NFS-директории по вайфаю (который коннектится после логина в иксы)? Раньше в убунтах проблем как-то не было, сейчас что ни пиши в /etc/fstab, какие опции по доке на mount ни давай, всё равно после логина и подъёма вафли шара недоступна некоторое время — минуты. Иногда приходится ручками делать sudo mount. Могу ошибаться, утверждая что вафля поднимается после логина а не сразу (минт 19).
                              +2
                              я после безуспешных приседаний с fstab NFS монтирую mount-юнитом:

                              # /etc/systemd/system/mnt-mediastuff.mount
                              [Unit]
                              
                              [Mount]
                              What=192.168.1.250:/home/mediastuff
                              Where=/mnt/mediastuff
                              Type=nfs
                              Options=users,rw,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime
                              
                            +2
                            А можно примеры?
                        +2
                        А мне systemd нравится.
                          +8
                          Я не против systemd, для меня юнит-файлы действительно более удобны для деплоя и администрирования серверов и сервисов.

                          Но когда случайно во время работы узнаешь, что в systemd есть свой cron, свой ntp и ещё куча своих дублированных вещей, которым опять надо заново учиться из-за чьих-то фантазий… То немного пригорает :(
                            +2
                            Если у вас пригорает от того что «опять надо заново учиться», то вы, возможно, выбрали не ту профессию
                              +1
                              Нет, с профессией точно не ошибся — с удовольствием варюсь в теме, читаю хабр и другие ресурсы, смотрю вебинары, недавно вот на онлайн-курс DevOps записался :)

                              Но хочется изучать новые вещи, а не разбираться почему certbot использует крон от systemd, а не просто создал свое задание в /etc/cron.d/.

                              Вернее, даже так — мне и это интересно; ведь есть же причины, почему это создали и используют.

                              Но клиент ожидает [и обычно готов платить именно за это], что я просто поставлю и настрою за озвученное время инструмент. А вместо этого я вдруг узнаю что должен искать как смотреть таймеры в systemd (systemctl list-timers --all) и где редактировать таймер для certbot (/lib/systemd/system/certbot.timer).
                              И теперь я должен держать в голове два очень похожих инструмента, и проверять больше вещей.

                              А мог бы в это время почитать, например, чем firecracker лучше docker-а. Что для меня гораздо интереснее, чем изучение путей в systemd :))
                                +2

                                Не надо редактировать файлы в /lib :) Обновление — и они имеют все шансы откатить ваши изменения.


                                systemctl cat certbot.timer
                                systemctl edit certbot.timer

                                  +1
                                  Благодарю за полезную информацию, побежал обновлять внутренние гайды :))
                              0
                              Из того, что там «есть свой cron» ещё не следует, что у Вас старый отобрали. Если хочется… гхм… минимализма и выпиливания лишних зависимостей — то будьте уж добры научиться, нет — используйте старый cronie (или что угодно), к которому уже прикручен юнит systemd.
                                –1
                                На некоторых проектах хочется стабильных, проверенных временем решений. Поставил последний Debian Stable, накатил apache+php+https и отдал клиенту.

                                А по факту — чтение док и выяснение почему в системе 2 крона и как редактировать задания для нового, потому что какой-то пакет стал вдруг использовать его.
                                  +2
                                  Аааа. У нас тут админ локалхоста, который ставит апач. Ну тогда больше нет вопросов. Ты начитался на ЛОРе, что системд это плохо, но чем же плохо ты сказать не можешь, ведь фрики с ЛОРа не пишут чем плохо, а просто пишут «плохо»
                              +5
                              Я не верю в теории заговора и поэтому полагаю, что причины были в недостатках sysvinit и прочих СИ.

                              Ага. Основным из которых был, конечно же, фатальный недостаток. И, кстати, я лично абсолютно уверен, что существование заговоров это факт, а не теория — это довольно очевидно. Не знаю, имел ли заговор место в случае systemd, но я бы этому не удивился, иначе довольно сложно объяснить как его сумели быстро пропихнуть почти везде, не смотря на сильное сопротивление сообщества.


                              Созданная в 1983 г. sysvinit не умела решать ряд важных задач, таких как:

                              Ну, кроме sysvinit полно других нормальных систем, например runit из простых и s6 из навороченных.


                              • параллельный запуск процессов;

                              Конечно, линукс же перегружают постоянно, скорость запуска системы — это самое главное.


                              • обнаружение съемных носителей;

                              Действительно, они ведь съёмные, поэтому их постоянно втыкают в середине процесса загрузки… нет? Странно… а почему тогда об этом должна беспокоиться система загрузки?


                              • активизация сервисов на основе сокетов;

                              Ровно так же ненадёжна, как и любой другой метод. Если сервис начал слушать порт — это вовсе не означает, что он не упадёт тут же, и в принципе будет обслуживать запросы. Это типичный пример решения несуществующей проблемы — идея неплохая, но реальной пользы от неё мало, и уж точно она не стоит той цены, включая конфликты в сообществе, которую уплатили за внедрение systemd.


                              • надежно контролировать зависимости между различными процессами и службами;

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


                              • раннее логирование событий через /dev/log.

                              Честно говоря, я понимаю, почему логи терять нельзя. Чего я не понимаю, так это почему у меня сервис syslog (точнее, выполняющий эту роль socklog-unix) под runit запускается больше десятка лет на куче серверов одновременно со всеми остальными сервисами, без контроля зависимостей и всего такого, и никогда это не стало причиной каких-либо проблем. Ой, стойте, понимаю — systemd опять решил несуществующую проблему.

                                +5
                                И снова бессмысленная фича, решающая несуществующую проблему. Да, есть начальный этап загрузки

                                При чём тут загрузка?


                                systemctl restart foo.target — перезапускает сразу несколько связанных сервисов. Пример из жизни #1: приложение на Python/Django с воркером Celery, код единый, при деплое нужно перезапустить оба сразу.


                                Пример из жизни #2: мы запускаем oneshot юнит от юзера (с ограничениями ProtectSystem=strict, сброшеные capabilities), но нам надо после того, как он отработал, сразу же автоматически запустить другой oneshot юнит от рута без ограничений. Делается с помощью зависимости After=bar.service. Либо опять городить нечитаемый bash скрипт.


                                Запускаем systemd-cgls — сразу видна картина, что запущено, для чего. Особенно если зашли на чужой сервер и надо за 60 секунд понять, что там работает. При этом неважно, это Debian, Ubuntu, Centos, RHEL, всё одинаково, все процесы отсортированы по группам. Кто у нас ещё умеет cgroups использовать по полной? runit умеет?


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

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

                                  +2
                                  при деплое нужно перезапустить оба сразу

                                  sv t myservice1 myservice2
                                  Либо, что встречается намного чаще: docker stack deploy -c myservice.yml myservice


                                  сразу же автоматически запустить другой oneshot юнит от рута без ограничений

                                  Просто любопытно, что конкретно делают эти юниты, откуда такие странные требования? И не тот ли это случай, когда из-за того, что инструмент даёт возможность делать странное мы начинаем это странное делать, вместо того, чтобы подумать лишние пять минут и сделать нормально?


                                  Либо опять городить нечитаемый bash скрипт.

                                  А почему, собственно, не читаемый? На баше можно писать вполне читаемо, и на нём написано очень-очень много, сколько бы фич не добавляли в systemd он всё-равно не сможет заменить все баш-скрипты на конфиг-файлы.


                                  При этом неважно, это Debian, Ubuntu, Centos, RHEL, всё одинаково, все процесы отсортированы по группам.

                                  Уверяю Вас, есть множество серверов, на которых systemd нет. С тем же успехом я могу сказать, что заходя на любой из моих серверов похожую картину можно увидеть запустив srvstat, а вот systemd-cgls на этих серверах выдаст только "command not found: systemd-cgls".


                                  Кто у нас ещё умеет cgroups использовать по полной? runit умеет?

                                  Нет. Докер умеет. И именно в докере обычно деплоятся все наши проекты. А использовать cgroups для системных сервисов вроде ssh, cron и syslog… можно, если получаешь это из коробки как в systemd, но, если честно, какого-либо реального эффекта на их работу или работу системы в целом наличие или отсутствие cgroups для этих сервисов — не оказывает. Иными словами, как я уже писал — очередная бесполезная фича, классная на первый взгляд, но на практике ничего не меняющая.

                                    +4
                                    sv t myservice1 myservice2

                                    А потом появился myservice3, про него забыли и т.п. И про докер не надо, это уже другой уровень абстракции.


                                    Просто любопытно, что конкретно делают эти юниты, откуда такие странные требования?

                                    Ничего странного. Это случай из жизни — запускаем dehydrated для обновления сертификатов Let's Encrypt. Т.к. ему не нужны особые права, то запускаем от юзера. Потом надо от рута запустить reload сервисов, где сертификаты используются — для этого второй юнит, связанный с первым.


                                    sudo? Ну ок, а если хочется ему ограничить права, например так:


                                    ProtectSystem=strict
                                    PrivateDevices=true
                                    ProtectKernelTunables=true
                                    ProtectControlGroups=true
                                    CapabilityBoundingSet=
                                    PrivateTmp=true
                                    ReadWritePaths=/var/lib/dehydrated

                                    Опять же, вспоминаем, что unit не может быть запущен параллельно два раза, что сплошь и рядом встречается при запуске из крона (да, для этого надо ещё костылей городить, проверять pid файлы и т.п.)


                                    сколько бы фич не добавляли в systemd он всё-равно не сможет заменить все баш-скрипты

                                    Задачи заменить все баш скрипты никогда не ставилось.


                                    похожую картину можно увидеть запустив srvstat

                                    А user.slice как вы увидите? Или «это не надо»? Напоминаю, что systemd загоняет все процессы (кроме кернел тредов, конечно же) в какой-то вменяемо названный cgroup.


                                    Докер умеет.

                                    Про докер речь не идёт.


                                    реального эффекта на их работу или работу системы в целом наличие или отсутствие cgroups для этих сервисов — не оказывает

                                    Со временем все системные процессы, я надеюсь, будут переписаны с использованием cgroups для ограничения доступа, со сбросом не нужных для их работы capabilities, с фильтрами syscall'ов и тогда мы получим более надёжную и секьюрную систему «из коробки». Сейчас так обычно не делается, потому что на баше это выливается в десятки строк.


                                    А ещё есть systemd.resource-control — как вы в скрипте ограничите I/O процесу? Или макс. количество тасков в cgroup?


                                    Конечно, всё это делается на баше, но скрипт всё растёт и растёт.

                                      –3
                                      А потом появился myservice3, про него забыли и т.п.

                                      Ровно с тем же успехом можно забыть прописать зависимость между unit-файлами.


                                      И про докер не надо, это уже другой уровень абстракции.

                                      Почему, собственно? Докер делает ровно то, что Вы тут описываете — запускает и перезапускает сервисы, группами, изолирует их, показывает текущее состояние, etc. И при этом он не пытается заставить нас вообще всё делать только через него.


                                      Ещё раз.


                                      Есть загрузка системы и запуск системных сервисов вроде ssh/cron — это одна задача, и для этих сервисов нет заметной пользы от использования изоляции, сложного контроля зависимостей, etc. Это — факт, подтверждённый всеми существующими серверами без systemd.


                                      А есть другая задача — запуск наших собственных приложений/сервисов, нередко написанных достаточно быстро/грязно, с запутанными внутренними зависимостями, etc. Такие сервисы намного эффективнее деплоить в формате контейнеров, и запускать под докером/k8s, с поддержкой cgroups, управлением сложными внутренними зависимостями, ограниченным root, etc.


                                      Можно запихнуть в systemd первую группу, но видимой пользы от этого нет. Можно запихнуть в systemd вторую группу, видимой пользы будет много, но если вместо этого запихнуть их в docker — пользы будет ещё больше, чем от systemd.


                                      при запуске из крона (да, для этого надо ещё костылей городить, проверять pid файлы и т.п.)

                                      PID-файлы проверять не нужно — помимо прочего, это не надёжно. Обычно всё, что для этого требуется, это утилитка из runit (или аналогичная из daemontools/s6) использующая банальную файловую блокировку и делающая exec в заданную команду:


                                      * * * * *  chpst -L .lock mycommand …
                                        +1
                                        Почему, собственно? Докер делает ровно то, что Вы тут описываете — запускает и перезапускает сервисы, группами, изолирует их, показывает текущее состояние, etc. И при этом он не пытается заставить нас вообще всё делать только через него.

                                        Еще как заставляет!


                                        1. Если у меня есть бинарник — я его могу запустить как демона хоть через sysvinit-скрипт, хоть через systemd-юнит, хоть через крон. Если у меня есть докер-образ — я могу запустить его только докером.


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


                                          0
                                          Внезапно, докер можно делать from scratch… И ничего лишнего!
                                          Это очень хорошо работает с приложениями на go, которые полностью инкапсулировано зависимости. С остальными — хуже, но тоже можно
                                            +2
                                            > С другой стороны, если у меня есть systemd, я могу с его помощью запустить любой бинарник.

                                            При чем я еще могу и запускать свои контейнеры, без докера, для всяких тестов пробовал systemd-nspawn, чертовски удобная пепяка. Хотя для продакшена предпочитаю lxc для контейнеров.
                                            0
                                            Докер и групповой запуск?
                                            Вы сейчас шутите?
                                            Докер как раз ЭТУ проблему не решает.
                                            Все равно приходится обмазываться внешними средствами: от баш скриптов и докер-компоузов до полноценных оркестраторов типа куба
                                            И, да, докер-контейнеры можно описывать как системд юниты. Вполне себе best practice

                                            На всякий случай поясню: пихать софт в докер — хорошая (в целом) идея. Можно контейнеры вообще на чем-то типа atomic или coreos гонять — ещё лучше. Но сам по себе он (docker) решает одну единственную задачу.
                                              0

                                              docker swarm вполне встроенный способ это делать.

                                                0
                                                Это скорее про реплики, а не зависимости между сервисами.
                                                  0

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

                                                    0
                                                    Ещё раз. Для нескольких контейнеров можно использовать тот же докер-компоуз. Или portainer. Или даже такое: vmware.github.io/admiral

                                                    Касательно зависимостей. Предположим, что у Вас есть набор контейнеров:
                                                    * Базы данных
                                                    * Миграции
                                                    * Тесты
                                                    * Само приложение.
                                                    Решите задачу:
                                                    * Базы должны быть запущены постоянно
                                                    * После старта баз или по триггеру от пользователя должны накатиться миграции
                                                    * После миграций — стартуют тесты
                                                    * Если тесты успешные — должны стартануть контейнеры с приложением
                                                    В рамках куба это можно красиво.
                                                    В остальном — пришлось мудрить с хелсчеками и баш обёртками.
                                                    Я уж не говорю, если пришлось бы какой-либо контейнер запускать по таймеру (крон, да?)
                                                    Ес-но не хочется оставлять контейнеры после того, как они выполнили свою функцию. Но это и ставит крест на запуске докер-компоуз с ключом --abort-on-exit
                                                      0
                                                      • Базы должны быть запущены постоянно

                                                      docker stack deploy не будет перезапускать контейнер при перевыкате сервиса, если описание конкретно этого контейнера не поменялось в новой версии сервиса.


                                                      • После старта баз или по триггеру от пользователя должны накатиться миграции

                                                      Зачем так запутанно? Миграция БД всегда связана с выпуском новой версии приложения, и накатывается в момент запуска этой версии, внутри контейнера этой версии. Можно, конечно, вынести выполнение миграции в отдельный контейнер, но это имеет смысл только если у вас разные сервисы работают с общей БД, что плохо само по себе, и вызывает кривизну в других местах вроде этого.


                                                      • После миграций — стартуют тесты
                                                      • Если тесты успешные — должны стартануть контейнеры с приложением

                                                      Какие ужасы. Я тесты гоняю на CI. А когда идёт перезапуск приложения на prod/staging то там уже никаких тестов нет, контейнеры с приложением запускаются всегда.


                                                      Итого — обёрток ноль, всё делается банальным обновлением тега образа с нашим сервисом (собранного на CI после прохождения тестов) в yml-файле описывающем стек и запуском docker stack deploy. Миграции выполняет либо сам сервис при запуске, либо shell-скрипт запускающий сервис сначала выполняет команду, которая проверяет версию схемы БД и выполняет необходимые миграции, а потом запускает сервис — да, этот двухстрочный скрипт можно гордо назвать "обвязкой", нет, никаких проблем она не создаёт.


                                                      Я уж не говорю, если пришлось бы какой-либо контейнер запускать по таймеру (крон, да?)

                                                      Да, причём не контейнер по крону, а контейнер запущенный всегда, внутри него — обычный крон-сервис, который запускает что и когда нужно.

                                                        0
                                                        Да, причём не контейнер по крону, а контейнер запущенный всегда, внутри него — обычный крон-сервис, который запускает что и когда нужно.

                                                        Уже кривизна. Почему не воспользоваться кроном на хостовой машине?
                                                        Какие ужасы. Я тесты гоняю на CI. А когда идёт перезапуск приложения на prod/staging то там уже никаких тестов нет, контейнеры с приложением запускаются всегда.

                                                        К сожалению не весь пишем мы и не весь софт из мира поней и единорогов.
                                                        Ещё раз повторю вопрос — сложные зависимости пробовали реализовывать?
                                                        Ну, судя по ответам — нет.
                                                        Вопрос «нафига они нужны» — он за скоупом нашего разговора
                                                        Кстати, systemd с этим прекрасно справляется
                                                          0
                                                          Почему не воспользоваться кроном на хостовой машине?

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


                                                          Кроме того, когда этот сервис мигрирует (или масштабируется) между серверами, то намного удобнее когда абсолютно всё его хозяйство, включая настройки крона, мигрируют штатным образом — а для этого они должны быть внутри контейнера этого проекта, а не в systemd сервера, на котором он когда-то в прошлом запускался.


                                                          Ещё раз повторю вопрос — сложные зависимости пробовали реализовывать?

                                                          Не такие, как Вы описываете. Когда я сталкиваюсь с таким, то я просто переделываю это нормально — моя задача решить проблему заказчика, а не механически выполнять идиотские требования "настроить накат миграций именно таким конкретным кривым способом". По сути, когда я попадаю на новый проект, то первое, что я там делаю — настраиваю нормально CI/CD, потому что писать код без этого я уже давно разучился.

                                                            0
                                                            моя задача решить проблему заказчика, а не механически выполнять идиотские требования «настроить накат миграций именно таким конкретным кривым способом».

                                                            повторюсь — речь не про миграции как таковые. Речь про то, что докер из коробки не умеет нормальные сложные зависимости между сервисами. Решается обвязками. Можно башем. Можно systemd. Можно вообще отдельный служебный контейнер, который будет имплементировать эту логику.
                                                            когда этот сервис мигрирует (или масштабируется) между серверами, то намного удобнее когда абсолютно всё его хозяйство, включая настройки крона, мигрируют штатным образом

                                                            Дискуссионный вопрос — сколько должно быть кронов и где они должны быть (запросто, что крон джоб должен быть в единственном экземпляре). Самое верное, имхо, мигрировать в куб.

                                                            Мы действительно используем докер на standalone хостах, потому что это удобно и круто.
                                                            В других проектах — куб.
                                                            Каждой задаче — свои инструменты.
                                                            По сути, когда я попадаю на новый проект, то первое, что я там делаю — настраиваю нормально CI/CD, потому что писать код без этого я уже давно разучился.

                                                            и как это релевантно к «докер из коробки не умеет нормальные сложные зависимости между сервисами»?
                                                              0
                                                              нормальные сложные зависимости

                                                              А Вы ещё не устали считать сложность — нормой? Я вот давно устал. Поэтому стараюсь делать всё как можно проще. Получается… ну, чаще получается, хотя и не всегда, к сожалению.


                                                              Когда используемый инструмент позволяет делать вещи сложно не испытывая от этого заметного дискомфорта — многие тут же радостно делают сложно… потому что для того, чтобы сделать просто — надо сначала хорошо подумать, а думать без острой необходимости многие избегают. Так что лично я предпочитаю использовать инструменты, которые не считают сложное нормой и не провоцируют делать сложно — они помогают мне находить более простые решения текущей задачи.


                                                              Конечно, возможностей простых инструментов иногда не хватает. Но я предпочитаю брать сложные не раньше, чем это произойдёт — и происходит это, на самом деле, не так уж часто.


                                                              и как это релевантно к «докер из коробки не умеет нормальные сложные зависимости между сервисами»?

                                                              Простите за вырванную из контекста цитату выше, она была нужна чтобы подготовить контекст для ответа на заданный вопрос.


                                                              Это релевантно потому, что взяв изначально более простые инструменты (runit вместо systemd, docker вместо k8s) я мотивирую себя решить задачу настройки CI/CD более простым способом, чтобы обойтись без многократно упомянутых портянок/костылей на баше. Что, в свою очередь, нередко приводит к необходимости сначала подчистить проект, как именно в нём делаются миграции, какие у него зависимости между сервисами, etc. — и, что характерно, такой подход пока что всегда шёл на пользу проекту.

                                        –1
                                        А в systemd нельзя громкость еще менять? А то это тоже не унифицировано — мне неудобно.
                                        +3
                                        я лично абсолютно уверен, что существование заговоров это факт, а не теория — это довольно очевидно

                                        Голая вера и ничего больше. Вообще, конспирология это римейк веры в злобных демонов. Человеку проще не принимать во внимание, что другие люди могут мыслить иначе и не считать его идеи великим благом. Ему проще верить в тайных негодяев и вредителей.

                                        скорость запуска системы — это самое главное

                                        Может и не самое главное. Но когда в 2018 году система с многоядерным процесором и SSD грузится по 40 секунд это позорище.

                                        бессмысленная фича

                                        решил несуществующую проблему

                                        Я тоже не понимаю, почему разработчики решают кучу всяких «несуществующих» проблем, ведь всем известно, что Linux существует исключительно для powerman и его задач XD
                                          +1
                                          Но когда в 2018 году система с многоядерным процесором и SSD грузится по 40 секунд это позорище.

                                          Откуда Вы взяли эту цифру? Я вот не поленился, и специально только что перегрузился несколько раз с секундомером. Мой Gentoo с runit загружается в "серверном" стиле (без X-oв и нужных только им сервисов) за 5.5 секунд. Если грузить в обычном режиме, как десктоп, то загрузка занимает примерно 40 секунд, но учтите, что сюда входят:


                                          • 60 runit-сервисов (включая vpn, без которого упомянутые ниже браузер сотоварищи бы не запустились нормально)
                                          • ручной ввод пароля
                                          • запуск 20-ти терминалов, некоторые терминалы сразу с приложениями (mc, mutt, rtorrent, несколько ssh на сервера)
                                          • pidgin, keepass, dropbox…
                                          • и, самое главное — нескольких окон браузера с тучей вкладок в каждом

                                          Таймер остановил глядя когда не просто все они полноценно отрисовались, но и нагрузка на CPU упала, т.е. даже браузер закончил грузиться.


                                          Насколько лучше сделает то же самое systemd, и, самое главное, насколько это важно?

                                          0
                                          Действительно, они ведь съёмные, поэтому их постоянно втыкают в середине процесса загрузки… нет? Странно… а почему тогда об этом должна беспокоиться система загрузки?

                                          Потому что бывают носители, которые только притворяются съёмными, но на самом деле являются системными.

                                            0
                                            Потому что бывают носители, которые только притворяются съёмными, но на самом деле являются системными.
                                            Кстати, а если папка с данными для загрузки такой системы находится на таком носителе, это отдельный случай или нет?
                                            0
                                            На самом деле для облачных хостов systemd реально выглядит оверкиллом, т.к. там весь список оборудования стандартен. И нет необходимости подключать внешние накопители и т.п.
                                            Но с другой стороны удобно, что среда на облачных хостах и реальных серверах одинаковая. Не надо переучиваться…
                                              +4
                                              Какое отношение systemd имеет к внешним накопителям? А нормальное управление сервисами нужно хоть в облаке, хоть на домашнем компе, хоть на железном сервере, нормальное управление дают юниты и никогда не давал sysV-init.
                                                0
                                                Ronald_Riley смотря, что Вы имеете в виду под внешним накопителем. Если это каталог, монтируемый по nfs, то его можно тоже в systemd target засунуть и обеспечить последовательность запуска сервисов. Кстати, я и не спорил, что systemd решает эту задачу. Я про другое: ОН действительно монструозен и было бы круто иметь простое решение для виртуализированных или любых других стандартизированных сред.

                                                P.s. про внешние накопители типа usb — это к ребятам выше, они про такие «съёмные» накопители говорили
                                            +6

                                            Любители механики восстанавливают классические автомобили, любители ПО поддерживают классический init. У каждого своё хобби.


                                            Банально нет ни одного пункта, по которому sysvinit может выиграть в надёжности и безопасности на современном сервере. Даже элементарный запуск сервиса на systemd написать проще чем через init.d, не говоря уже о контроле работы. Замена cron снимает множество проблем, а "дублированный функционал" легко отключается, если требуется более полное решение.


                                            Упёртость отдельный коллег лишь показатель тупика, в который они себя загнали протестом.

                                              +1

                                              На daemontools/runit/s6 запуск сервиса написать ещё проще. Вот вам примеры, и покажите, насколько проще выглядит вариант systemd:


                                              • /etc/service/ssh/run:
                                                #!/bin/sh
                                                exec /usr/sbin/sshd -D 2>&1
                                              • /etc/service/nginx/run:
                                                #!/bin/sh
                                                ulimit -n 8192
                                                exec nginx -g 'daemon off;'
                                              • /etc/service/docker/run
                                                #!/bin/sh
                                                exec dockerd 2>&1

                                              И какие конкретно проблемы, точнее, множество проблем, снимает замена cron?


                                              Хотя нет, не будем ждать милостей от природы, я сам добавлю пример "простого" сервиса на systemd — скажу честно, не выбирал, взял тупо первый, который гарантированно будет на сервере с убунтой:


                                              • /etc/systemd/system/sshd.service:

                                              [Unit]
                                              Description=OpenBSD Secure Shell server
                                              After=network.target auditd.service
                                              ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
                                              
                                              [Service]
                                              EnvironmentFile=-/etc/default/ssh
                                              ExecStartPre=/usr/sbin/sshd -t
                                              ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
                                              ExecReload=/usr/sbin/sshd -t
                                              ExecReload=/bin/kill -HUP $MAINPID
                                              KillMode=process
                                              Restart=on-failure
                                              RestartPreventExitStatus=255
                                              Type=notify
                                              RuntimeDirectory=sshd
                                              RuntimeDirectoryMode=0755
                                              
                                              [Install]
                                              WantedBy=multi-user.target
                                              Alias=sshd.service
                                                +7

                                                Добавьте всё, что делает этот Unit в ваш пример daemontools и без костылей не обойдётесь. По факту, нужны только ExecStart и WantedBy в соответствующих разделах. Лет 10 назад daemontools был незаменим, но сейчас systemd уже на голову выше.


                                                systemd timer активирует сервис, который запускается по расписанию со всеми гарантиями и плюшками в виде cgroups, limits, namespaces и journal. В простом cron запускается команда, которую требуется дополнительно обезопасить хотя бы от двойного запуска — это самая частая проблема.


                                                К слову, когда-то уже упоминал, что изначально тоже был противником systemd.

                                                  +2

                                                  А зачем мне всё это? Нет, серьёзно, что такого делает демон ssh на ваших серверах, чего не делает на моих? Давайте я скажу, что он делает на моих: очень надёжно запускается, и, при необходимости (мной вручную, или автоматически после падения), не менее надёжно перезапускается. А всё остальное время — просто работает. И остальные сервисы на моих серверах под runit делают ровно то же самое: они всегда гарантированно запущены и просто работают. runit позволяет очень просто настраивать их запуск (примеры выше), удобно смотреть их текущее состояние, запускать/перезапускать/останавливать. Плюс, важная фишка, не менее надёжно, качественно, удобно и единообразно вести логи всех сервисов через svlogd — с фильтрацией, ротацией, etc. … и даже, Вы не поверите, в текстовом формате! :)


                                                  Я никогда не спорил с тем, что у systemd намного больше фич… я высказывал обоснованное сомнение в нужности и полезности этих фич, а так же в том, что они окупают недостатки systemd.

                                                    +3
                                                    Системд позволяет легко прописывать зависимости. Банальный пример — сервер запускается после старта сети.
                                                    А еще мне баш совершенно не понятен, я питоном и джавой балуюсь. Вот системд позволит в легкую мне настроить все что нужно для работы моих сервисов, без надобности дебажить(через echo) портянку баш скриптов. Да я знаю, что на нем даже игры пишут, но для меня это какой-то брейнфак и мне не хочется тратить время на его изучение.
                                              +5
                                              Не понимаю почему нельзя было оставить systemv как основную систему инициализации, а systemd как опцию для тех кому она нужна. Для одноразовых скриптов systemv мне была удобнее, потому что нужно было бороться только со скриптом, а не с целой системой инициализации. Systemd вообще никаким образом не помогает от сдохших сервисов, для этого вообще-то специальные системы мониторинга есть. Иногда она их перезапускает, иногда нет(хотя может у меня руки кривые). Наверное даже для случаев когда сервис висит на порту но не реагирует есть у systemd какой-то костыль, но по сути это будет тот же мониторящий скрипт через обертку systemd.

                                              Замыкать фичи десктопных сред на систему инициализации от которой может быть польза только матерым админам это вообще сильно. И как вишенка на торте — не все авторы софта или ментейнеры дистров сами хорошо разбираются в systemd, в итоге приходится переписывать юниты самому.

                                              Наверное профессиональным администраторам linux стало легче с появлением systemd, но почему нельзя было сделать ее такой же опцией как и selinux, который тоже системе в кишки залезает, но пока его не поставишь, все работает и без него?
                                                +4
                                                что нужно было бороться только со скриптом, а не с целой системой инициализации

                                                С чем конкретно вам бороться нужно было? Вот минимально необходимый unit, чтобы сервис работал (причём, если не надо его запускать после ребута автоматом, то достаточно 2 первые строки):


                                                [Service]
                                                ExecStart=/bin/sleep 100
                                                [Install]
                                                WantedBy=multi-user.target

                                                Вы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?


                                                Systemd вообще никаким образом не помогает от сдохших сервисов

                                                Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.


                                                фичи десктопных сред на систему инициализации

                                                Какие конкретно?


                                                не все авторы софта или ментейнеры дистров сами хорошо разбираются в systemd

                                                Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.


                                                но пока его не поставишь, все работает и без него?

                                                Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?

                                                  +4
                                                  А если процесс подвис

                                                  Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET. Для скриптов есть консольная утилита systemd-notify.

                                                    0
                                                    Насколько я понял это работает только в случае, если в сервисе уже есть механизм для отсылки нотиса вотчдогу. Т.е. скорее всего придется опять писать старый добрый шелл скрипт, которые бы хитро следил за процессом и посылал уведомления?
                                                      +1

                                                      Да, я именно так и написал


                                                      единственное, что требуется от сервиса, уметь периодически слать sd_notify

                                                      Придется накостылять скрипт или просить разработчиков сервиса добавить такую функциональность. Ведь по другому никак не узнать именно о зависании. Вообще systemd не запрещает писать скрипты и не думаю, что для фанов sysvinit это проблема. Тем более, если такая функциональность уже была в sysvinit скрипте, то останется добавить только одну строчку с вызовом systemd-notify

                                                        0

                                                        Скрипт не поможет, потому что отсылать должен $MAINPID, иначе будет так:


                                                        Dec 04 09:27:02 host systemd[1]: test-notify.service: Got notification message from PID 9274, but reception only permitted for main PID 9267
                                                          +1

                                                          В этом должны помочь: директива юнита NotifyAccess= и опция --pid=

                                                      –3
                                                      Вы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?


                                                      #!/bin/sh
                                                      /bin/sleep 100
                                                      


                                                      И положить в нужный мне rc.* Поймите, я не профессиональный админ, и мне это правда проще, чем читать документацию по systemd и всем ее возможностям.

                                                      Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.


                                                      А не логичней ли, если вам правда нужно чтобы сервис гарантировано жил, использовать таки полновесную систему мониторинга, а не штуку, которая иногда рестартит, иногда нет?

                                                      Какие конкретно?


                                                      В статье ищите по слову Gnome.

                                                      Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.


                                                      Самое смешное забыл, до сих пор куча юнитов — это просто обертка над теми нелюбимыми вами shell скриптами. Потому что нельзя всегда всю логику инициализации сервиса запихнуть в однострочную команду. Т.е. был просто добавлен слой асбтракции и все, по сути ничего не изменилось — шеловая портянка никуда не исчезла.

                                                      Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?


                                                      Проблема в том, что мне рядовому пользователю линукса на десктопе и веб-макаке по совмсестительству никакой пользы от systemd нет. Проблема в том, что завязывать целые пользовательские среды на systemd это странно, потому что помимо линукса есть есть *bsd, солярка, и все тот же линукс, но без systemd.
                                                        +1
                                                        А не логичней ли, если вам правда нужно чтобы сервис гарантировано жил, использовать таки полновесную систему мониторинга, а не штуку, которая иногда рестартит, иногда нет?

                                                        systemd реализует примерно аналогичные примитивы по мониторингу сервисов как и докер. И ничего — никто не жалуется. На самом деле, это правильный подход. Потому что то, что было раньше — с теми же PID-файлами — это тихий ужас. Я даже более того скажу — был у меня случай в практике, когда PID-файл сервиса был создан, в нем был записан PID. Сервис тихо сдох никого не уведомив, а другая приложуха этот PID захватила. Естественно, что после этого сервис было невозможно перезапустить штатно ))))
                                                        Проблема в том, что завязывать целые пользовательские среды на systemd это странно, потому что помимо линукса есть есть *bsd, солярка, и все тот же линукс, но без systemd.

                                                        проблема в том, что в КАЖДОЙ системе свой вариант системы инициализации. Буквально где-то в соседних комментах об этом говорилось.
                                                          +2

                                                          Нее, /bin/sleep 100 писать в rc.* нельзя. Как минимум, должно быть /bin/sleep 100 &. А еще нужно проверить первый аргумент, который может быть одним из вот этого списка: start, stop, restart, status, poll, enabled, rcvar...

                                                        +7
                                                        Для начала нет «systemv» — это вы что придумали. Наверное, речь про sysv-init. systemd отлично умеет перезапускать, придерживать перезапуск и обрабатывать падения сервисов.

                                                        Более того, systemd — единственный из всех инициализаторов, который может при завершении (stop) гарантировано прибить всё, что нафоркал демон. Ни upstart, ни sysv-init физически не имеют возможности трекать потомков.
                                                          +1
                                                          Лично у меня openvpn падал без воскрешения, хотя иногда systemd его таки перезапускал, иногда нет. Я не знаю что это было — баг в openvpn, баг в конкретной версии systemd или мои кривые руки, но впечатление осталось. В итоге написал свой шелл скрипт, который мониторил по крону.
                                                            +1
                                                            Я не знаю что это было — баг в openvpn, баг в конкретной версии systemd или мои кривые руки

                                                            Слишком мало информации для анализа. :)

                                                              0
                                                              Часто именно в этом и смысл
                                                              +2
                                                              падал без воскрешения, хотя иногда systemd его таки перезапускал

                                                              Потому что «проверенную временем» схему с форком и уходом в background надо безжалостно выпиливать везде где только можно. В случае с openvpn это опция daemon (её найти и удалить).


                                                              В вашем случае, скорее всего, openvpn форкался и в таком случае systemd может и не отследить, что сервис упал.

                                                                –1

                                                                Кстати, у меня под убунтой тоже пару раз openvpn пришлось руками перезапускать. Сейчас глянул:


                                                                # grep daemon /lib/systemd/system/openvpn@.service
                                                                ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid

                                                                И вот вопрос, почему же штатный пакет openvpn убунты годами распространяется с таким конфигом под systemd, который не в состоянии обеспечить стабильный перезапуск сервиса?
                                                                Я бы предположил, что дело в том, что systemd очень богат ненужными фичами — тот же runit поддерживает только сервисы, которые не отцепляются от родителя, поэтому под ним openvpn с --daemon никому даже не приходит в голову запускать, ведь это тупо не сработает.


                                                                В результате мы имеем факт: под runit openvpn перезапускается гарантированно, а под systemd — нет. И чья это вина, systemd или разработчиков пакета openvpn — как минимум не очевидно.

                                                                  +1
                                                                  распространяется с таким конфигом под systemd, который не в состоянии обеспечить стабильный перезапуск сервиса

                                                                  Маинтейнеры тоже, бывает, не любят документацию читать. Вообще, это копипаста из дебиана (там тоже --daemon). По хорошему, надо бы баг зарепортить, конечно.


                                                                  systemd очень богат ненужными фичами

                                                                  Это сделано для совместимости, чтобы systemd-sysv-generator(8) нормально работал, потому что в случае с sysv init нормальное поведение — это форкающийся демон. Подозреваю, что в будущем эту штуку удалят.


                                                                  runit поддерживает только сервисы

                                                                  runit никогда не заявлял совместимость с sysv init, равно как не претендовал на его полную замену (хотя в радикальной конфигурации его вроде даже можно как init запускать, размуеется, переписав вначале все скрипты запуска сервисов).


                                                                  И чья это вина

                                                                  Ничья. Если бы openvpn упал в системе с sysv init его бы никто даже не пытался бы перезапустить.

                                                                    –1
                                                                    его вроде даже можно как init запускать

                                                                    Можно, у меня так везде. Скрипт запуска меньше 300 строк, очень просто, наглядно и удобно. Кстати, я лет 10 назад об этом тут писал (https://habr.com/post/21205/), и с тех пор ничего не изменилось — по-прежнему очень удобно, поддержка этих скриптов занимает примерно пол часа раз в 3 года, используются на кучке домашних машин и кучке серверов, работают как часы.


                                                                    Люди вообще отвыкли от простых решений, добавляют accidental complexity в диких количествах везде, куда дотянутся. Вы давно работали с системой, у которой абсолютно весь код выполняемый при загрузке, запуске каждого сервиса, и выключении системы занимал 400 (на сервере) или 611 (на десктопе) строк на bash? Подозреваю, что вообще никогда. А для меня это — норма. Я хочу иметь возможность за пол часа-час прочитать и понять всё, что при этом происходит, чтобы иметь возможность легко сопровождать систему.


                                                                    Если бы openvpn упал в системе с sysv init

                                                                    Я вот не очень понимаю, с кем Вы сейчас разговаривали. Я разве хоть слово про sysvinit в комментариях к этой статье сказал? sysvinit это кошмар, безусловно, но systemd это тоже кошмар, просто совершенно по другим причинам. Давайте сравнивать systemd с нормальными альтернативами, вроде runit/s6.

                                                                      0
                                                                      Маинтейнеры тоже, бывает, не любят документацию читать. Вообще, это копипаста из дебиана (там тоже --daemon). По хорошему, надо бы баг зарепортить, конечно.


                                                                      Так в этом и проблема! Документацию читать никто не любит, особенно для вещей, которые не являются основной специализацией. Это человеческий фактор от которого никуда не деться, везде одно и то же — от программных пакетов до языков программирования. Никто не будет помнить всех тонкостей systemd, если он пишет новый юнит раз в полгода. И мы еще годами будем переписывать юниты ручками, особенно в LTS.

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

                                                                      Да, systemd по всему набору фич чем любая альтернативня система инициализации. Но эти фичи никому нахрен не вперлись кроме матерых админов и девопсов. Но почему-то selinux и app-armor при всей их сложности смогли сделать опциональными, а systemd запихнули намертво. Да, sysv-init кривая, но с ней по крайней мере умели работать и мейнтейнеры и пользователи, админам должно быть пофиг что учить — им за это деньги платят. Т.е. это верх идиотизма выходит — мейнтенеры не выиграли, обычные пользователи не выиграли, а админы и так могли бы накатить себе systemd раз она такая замечательная, но нет лучше сделать по дефолту именно ее.
                                                                      +3
                                                                      форкающиеся сервисы прекрасно отлавливаются по падению и перезапускаются. Весь вопрос, там restart on-failure или always?

                                                                      Посмотрел, там такое:
                                                                      Type=notify
                                                                      Restart=on-failure

                                                                      Если вышло успешно, то перезапускать не будет. Если неуспешно — перезапустит. Чтобы перезапускало всегда — Restart=always.
                                                                    +1
                                                                    Достаточно написать в unit'е Restart=always (обычно там «on-failure»). Если у вас при always не рестартили, то это major bug и про это можно кричать на каждом углу. Но я сильно сомневаюсь про существование такого бага.

                                                                    А если там on-failure, а openvpn вышел с кодом 0, то какие к systemd придирки?
                                                                      0

                                                                      on-failure. И это не придирки к systemd, это констатация факта, что и у меня и у PerlPower openvpn падал и не перезапускался под systemd, причём неоднократно. Возможно, это баг openvpn — я же не знаю, по какой причине он в те моменты завершался с кодом 0, я его об этом не просил. Возможно, это в пакете плохо написали unit-файл. Мне разве должно быть до этого дело? Под runit это не происходит, под systemd — случается, причём в конфигурации по умолчанию. Я не спорю, что под systemd можно всё настроить надёжно — я говорю, что под ним очень просто настроить не надёжно, что и происходит на практике.

                                                                        +2
                                                                        Послушайте, у вас в runit тоже можно написать «не перезапускать если код 0». В systemd существует штатный метод сказать «перезапускать всегда». Ваша критика сейчас звучит так:

                                                                        — А вот мой сосед взял дрель SystemD и не закрутил патрон, и там сверло не крутится.
                                                                        — Там на патроне есть полоска для того, чтобы закрутить, поверни её.
                                                                        — Какое мне до этого дело? У дрели RunIT, которую я взял у другого соседа патрон уже со сверлом и всё работает. Я не спорю, что у SystemD дрели можно закрутить патрон — я говорю, что там очень просто получить от соседа дрель с незакрученным патроном, что и происходит на практике.
                                                                          –1

                                                                          Лучше провести аналогию с языками со статической и динамической типизацией. У обоих хватает сторонников, но считается, что первые заметно усложняют процесс выстрела себе в ногу. Я 18 лет писал на Perl и не могу сказать, что сильно страдал от отсутствия типов, хотя изредка, не смотря на все старания писать чистый код, это приводило к багам. Сейчас пишу на Go и не могу сказать, что я стал фанатом статической типизации… тем не менее, очевидно, что написать некорректный код на Go заметно сложнее, чем на Perl, и такой код будет намного сильнее "бросаться в глаза".


                                                                          Здесь ситуация похожая: run-скрипт на runit, который останавливает сервис если он завершился с кодом 0 — это большая редкость плюс ручная обвязка на шелле, такое сильно заметно, и по ошибке такое не напишешь. В случае же systemd — нифига эти нюансы не заметны, и, как мы видим, по ошибке или нет, но такое делают.


                                                                          Я не против сложных и навороченных приложений. Любимые мной vim и mutt явно попадают в эту категорию, как и zsh. Но я не хочу видеть такую гибкость и сложность в приложении, отвечающем за загрузку системы и стабильность работы всех сервисов — в этом случае мне намного важнее её очевидность и надёжность.

                                                                            +3

                                                                            Блин, это не нюансы а конкретная фича. Её кто-то руками написал. Взял и написал Restart=on-failure. Это как я бы в статически типизированном языке Rust написал бы unsafe{ всякая пакость} а потом бы заявлял, что язык позволяет делать всякую пакость если я написал unsafe. Я не понимаю каким образом неочевидным является поведение Restart=on-failure vs Restart=always. Более того, это написал мейнтейнер openvpn, а не попросили написать пользователя, так что это баг чистой воды.


                                                                            Я совершенно не понимаю вашей аргументации. runit не является init'ом, а сравнивая сложность написания юнитов для systemd с написанием, кхем, init.d скриптов (которых я в своей жизни наотлаживался больше, чем хочется), я могу сказать, что systemd — это мёд, да ещё и ложкой.


                                                                            Это реально инструмент, который берёт на себя всю грязную работу и все нюансы и выдаёт наружу чёткий интерфейс в обмен на декларативный конфиг.

                                                                              0
                                                                              runit не является init'ом

                                                                              Вообще-то, является.


                                                                              # qlist sys-process/runit | grep bin/
                                                                              /bin/runsv
                                                                              /bin/runsvdir
                                                                              /bin/chpst
                                                                              /bin/runsvchdir
                                                                              /bin/sv
                                                                              /bin/svlogd
                                                                              /sbin/runsvdir-start
                                                                              /sbin/runit-init        <--- это оно
                                                                              /sbin/runit
                                                                              /sbin/utmpset

                                                                              с написанием, кхем, init.d скриптов

                                                                              Вот. Опять. Я ничего не говорил про sysvinit и init.d скрипты. Я не хочу сравнивать sysvinit и systemd, я не хочу выбирать между ними двумя, категорически! Потому что да, я могу выбрать systemd. Не уверен, потому что очень уж меня раздражает systemd, но не исключаю, что выберу именно его. Потому что init.d — это просто за гранью добра и зла. Но я выбираю runit/s6, потому что они намного лучше и одного и второго, это просто золотая середина, не настолько навороченные как systemd, и не настолько ненадёжные как init.d скрипты.

                                                                +1
                                                                Во-первых, зрячий увидит, что при голосовании в дебиане конкуренция шла между systemd и upstart, старьё никто не хотел оставлять.
                                                                Во-вторых, вроде systemd никак философии юникс не противоречит, это множество маленьких демонов взаимодействующих между собой через единый интерфейс, детали отличаются, но суть вроде та же, я глубоко не копал, поправьте если ошибаюсь.
                                                                В-третьих, бинарность логов это никакая не проблема, а фича, которая даёт многое, например возможность индексирования, какая вам разница как храниться лог? В текст он легко превращается. Те же рассуждения и о бинарности протокола.

                                                                Ну и переход от написания скриптов к конфигам (unit файлам), это просто шаг в будущее, в первую очередь по причине безопасности, ну и читаемость выше за счёт унификации формата.
                                                                  0
                                                                  В общем опять каждый на себя одеяло тянет. Но нам, пользователям, не привыкать…
                                                                    +3
                                                                    «Сложный» systemd только тем, что он другой. если потратить немного времени на адаптацию (а это занимает реально меньше времени, чем баттхёрт в интернете) — он ничем не сложнее, чем то, чем вы там пользовались до этого. и уж фишечки с параллельностью, контролем за перезапуском, множественные инстансы и т.п. это серьезные плюсы.
                                                                      +8
                                                                      Когда я вижу рассуждения, что якобы systemd противоречит идеологии Unix™ я сразу делаю вывод, что передо мной человек, который если и видел Unix™, то только в кино, а к администрированию не имеет отношения. Все дело в том, что systemd — ближайший родственник launchd из OS X/macOS и smf из Solaris, которые таки являются сертифицированными Unix™. То есть если мы говорим не о некоем unix из фантазий диванных специалистов, а о реальном Unix™, тех ОС, которые имеют право так называться, то там, как раз, система инициализации родственна systemd по своей работе и идеологии

                                                                      Теперь о том, что якобы «в системд есть свой нтп, свой журнал, свой крон и так далее». А ТЫ НЕ ИСПОЛЬЗУЙ! systemd сугубо модульный и ты можешь не использовать модули, которые тебе не нравятся, вот просто не использовать и все, а использовать прежний инструмент.

                                                                      Ну а теперь мнение *nix-админа со стажем администрирования больше 20 лет(то есть мой стаж больше, чем возраст любого диванного systemd-хейтера в мире): systemd — лучшее что случалось с Linux-based OS за последние 20 лет. Вот просто лучшее. Это и прекрасные юнит-файлы, вместо портянок на шелле, это и зависимости при старте, это и ЕДИНЫЙ инструмент во всех основных дистрибах(раньше ты заходил и начинал вспоминать где тут надо сказать /etc/init.d/bla-bla restart, где service bla-bla restart, где restart bla-bla, а где еще какую-то фигню, теперь ты знаешь, что есть systemctl и пофигу это Debian/Ubuntu, это RHEL/CentOS или еще какой маргинальный SLES).
                                                                        +1
                                                                        Офигенная крутость решения systemd, что мы действительно перешли от кода (init скрипты) на конфигурационные файлы (каковыми и юниты несомненно являются). А дальше — легко их версионировать, хранить, выкладывать. Стоимость обслуживания падает, т.к. разбираться в портянках ьашей — это реально надо быть спецом. Сплошные плюсы.
                                                                        Минусы в том, что помимо systemd unit'ов иногда удобно хранить настройки в дефолтных файлах конфигов. Ну, и некоторые юниты от разработчиков сервисов ущербные. Взять ту же монгу. Выглядит очень мерзко, когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл. Решение? Общего не нашел, но можно делать свой юнит и класть его рядом со «штатным». Главное — потом не забыть, что там админ/разработчик понаписал.
                                                                          +1
                                                                          Ну, и некоторые юниты от разработчиков сервисов ущербные.

                                                                          Ну да, например в mongod.service указано Type=forking, однако надо при первой же возможности от форка избавляться. Монга сама умеет в foreground стартовать.


                                                                          когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл.

                                                                          А вы, надеюсь, правите не в /lib/systemd/system? Надо это делать в /etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.


                                                                          Решение? Общего не нашел,

                                                                          Например, systemctl mask some.service и делаем свой unit с немного другим именем.

                                                                            0
                                                                            А вы, надеюсь, правите не в /lib/systemd/system? Надо это делать в /etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.

                                                                            Спасибо за напоминание, Но вообще вопросы раскладки чего-либо по файловой системе всегда были дискуссионными. Тем более, когда используешь несколько разных дистрибов (ub/deb vs rhel/centos)
                                                                              +3

                                                                              В случае systemd есть стандартное соглашение по директориям, их функциям и приоритету. См. systemd.unit(5)

                                                                            0
                                                                            Так ведь юниты из пакетов и юниты написанные админом лежат в разных директориях, причем при совпадении имен вторые перекрывают первые…

                                                                            Как монга в таких условиях может переписать исправленный файл? Это точно минус systemd?
                                                                              0
                                                                              Ещё раз — я системд и не ругаю особо. Просто есть некоторые особенности работы с ней, которые нужно иметь в виду. А идеальный вариант — чтобы они сразу бросались в глаза, а не после ХХ часов опыта с этой штукой. Это тоже привело к тому, что мейнтейнеры стали бы писать нормальные юниты (а не как сейчас).
                                                                              +3
                                                                              По поводу юнитов от разработчиков… Разобраться в юните все равно всегда проще, чем читать простыню которую кто-то левой задней ногой писал то ли на пуре-шелл, то ли на баше, то ли еще на каком диалекте.
                                                                              Как правильно отметили ниже юниты из пакета должны идти в /lib/systemd/system, а твои личные в /etc/systemd/system и те которые из /etc/systemd/system при наличии одноименных в /lib/systemd/system имеют приоритет. Так что выход складывать свои на место, куда положено. А если мэйнтейнер складывает свои не туда, то бить ему по рукам.
                                                                                +3
                                                                                Добавлю ещё, что необязательно полностью копировать мантейнерский юнит ради одной правки, можно просто объединять их через .include, например:

                                                                                .include /usr/lib/systemd/system/httpd.service
                                                                                [Service]
                                                                                CPUShares=500
                                                                                  0

                                                                                  Overrides тут тоже отлично работают, что и делает команда systemctl edit

                                                                                +2

                                                                                systemctl edit mongo и редактируйте до посинения. При этом всё будет обновляться с сохранением изменений и бла-бла-бла.

                                                                                  0
                                                                                  del
                                                                                –3
                                                                                Леннарт Поттеринг может быть хорошим программистом
                                                                                В каком месте он хороший программист, если он даже философию сообщества не осилил?
                                                                                  +3
                                                                                  Не передёргивайте. sysv-init вообще занимался сервисами. Он занимался парсингом /etc/inittab и перезапуском того, что там написано.

                                                                                  А вот всё остальное — включая команду service и т.д. — это уже система инициализации, написанная на баше. Я бы сказал, что в этом месте её надо закапывать, но нет, на баше написана не только система, но и её файлы конфигурации. /etc/rc.d/foo — это не конфиг, это скрипт. Который при этом конфиг. Но тьюринг-полный. Мы все любим тьюринг-полные файлы конфигурации на bash.
                                                                                    +1
                                                                                    Да, ещё. Я могу понять причины сохранения sysv-init'а, но причин терпеть upstart никаких — кривая поделка с массой глюков и wtf, которую каноникал писала в своём стиле (стиле гугла?) — написать и закопать.

                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                    Самое читаемое