Несколько дней назад вышла в свет с опережением графика очередная версия классической Unix/Linux системы инициализации sysvinit 2.92. Предыдущий выпуск 2.91 вышел чуть больше месяца назад.
Что же примечательного в выходе минорной версии старинной системы инициализации (СИ), от которой отказались почти все современные дистрибутивы 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 г.
Итог голосования вызвал резкое чувство горечи, разочарования и несправедливости у противников 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 в Твиттере.
Ну хорошо, нет возможности выбора СИ, так ли это важно на самом деле? Не думаю, что меня сильно огорчит, если не будет возможности выбора загрузчика ОС, или клиента 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.
Дополнительное чтение
Комментарии (98)
gecube
03.12.2018 20:04+2Название статьи сделайте нормальное. Я бы ее провел с намного большим удовольствием, если понял сразу о чём идёт речь, а то «Debian» в качестве заголовко — ну, вообще верх минимализма
temujin Автор
03.12.2018 21:56Уже подправил, это была неудачная попытка использовать эмодзи символы в заголовке. Предполагалось название — Debian
andreymal
03.12.2018 22:53Хмммм... Ой, а где кнопка «Ответить»?apro
03.12.2018 21:01+2Почему обычные админы localhost-а не имеют возможности
Но есть же и плюсы, опыт управления localhost можно использовать
для управления любой машиной с Linux и даже не нужно разбираться что там
за дистрибутив.maxzhurkin
03.12.2018 22:16-2systemd один, но вот набор
костылейunit-файлов в каждом дистрибутиве свой (не то, чтобы они прямо кардинально различались от дистрибутива к дистрибутиву, но достаточно, чтобы ваше утверждение было преувеличением)
Krypt
04.12.2018 07:23Лично меня, как конечного пользователя, раздражают баги systemd. При этом меня совершенно не волнуют его фичи.
surefire
04.12.2018 08:38+2Уточните, пожалуйста, какие баги раздражают.
И был ли открыт по ним issue до вас или вами?Krypt
04.12.2018 22:38+1И последнего: подключаете sata hdd на внутренний разъём (например для диагностики), запускаете систему, делаете то, что хотели сделать, завершаете работу, отключаете hdd, включаете систему… а она не включается, потому что systemd запомнил guid файловой системы и не теперь не может его примонтировать.
Проблема известная и распространённая, последний раз когда я её смотрел она де факто была «won't fix».
У меня возникают вопросы:
— Нафига systemd вообще запомил guid ничего у меня не спрашивая?
— Почему невозможность примотнировать диск — фатальная ошибка?
Вообще, systemd как-то излишне похож на Nero Burning ROM и ASDSee последних версий перед тем как они канули в забвение.amarao
04.12.2018 23:16+1Вы какую-то ерунду описываете. GUID'ы есть не у файловой системы, а у разделов в GPT, и их не надо «запоминать», потому что они являются магическими константами, указывающими на тип содержимого. systemd точно не занимается вопросами выбора типа раздела на устройстве, так что либо у вас неправильная диагностика проблемы, либо вы не те слова используете для её описания.
Krypt
04.12.2018 23:47Я столкнулся с этой проблемой ~год назад, деталей я уже не помню. Linux на данный момент не является одной из тех os, которые я сейчас активно использую.
Про guid раздела вы правы. Запоминать их не надо, но systemd зачем-то это делает. Текст сообщения был вроде бы как «failed to determine partition table type» Лечением проблемы, соответственно, было найти файл со списком разделов и удалить лишнюю запись (и это были не команды для mount, а какой-то кастомный формат)
Я могу попробовать воспроизвести эту ошибку, если вы настаиваете.
amarao
05.12.2018 14:39GUID'ы файловых систем, разумеется, надо запоминать. 0FC63DAF-8483-4772-8E79-3D69D8477DE4 — linux filesystem data, CAFECAFE-9B03-4F30-B4C6-B4B80CEFF106 — ceph block data, etc. Но их не запоминают динамически, они где-то хардкожены в коде, и это в соответствии со спецификациями.
Воспроизведите, давайте посмотрим, что там происходит. Сколько я дисков не переподтыкал, ничего такого не наблюдал. Ни в бареметалле (и ноутбуках), ни в виртуализированной среде.
mayorovp
05.12.2018 08:49Если точнее, то у каждого раздела в GPT есть два гуида, первый является константой и обозначает тип раздела, а второй является случайным идентификатором. Вот второй-то как раз и запоминают.
amarao
05.12.2018 14:41Первый раз слышу про «два гуида в gpt». Есть guid, указывающий на тип раздела (аналог байтика «тип» в MBR), и есть uuid раздела.
mayorovp
05.12.2018 14:52+1guid и uuid — это синонимы
Согласно спецификации UEFI, в GPT Partition Entry есть PartitionTypeGUID и UniquePartitionGUID
surefire
04.12.2018 23:38То, что вы описали, никак не имеет отношения к systemd.
Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
устанавливает дефолтным загрузчиком Windows.Krypt
04.12.2018 23:52Нет, это не проблема с загрузчиком, так как ядро успешно грузилось. (OpenSuSE в моём случае). Решение на тот момент было успешно нагуглено и применено, просто деталей я уже не помню.
surefire
05.12.2018 00:41+1Собрав по кусочкам информацию от вас. Я пришёл выводу..
В данном случае 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 как всегда крайний.
Krypt
05.12.2018 02:05Подопытная операционка:
Linux 3.16.7-53-desktop
openSUSE 13.2 (Harlequin) (x86_64)
Опция root= действительно не указанна, но fstab на месте. .mount-файлов в /etc/systemd нет
Разделы вручную я не настраивал потому, что либо за меня это делал инсталлер, либо я это делал через интерфейс Yast'а.
А крайний systemd именно потому, что отвечает за монтирование разделов при загрузке.
skymal4ik
03.12.2018 22:45Я не против systemd, для меня юнит-файлы действительно более удобны для деплоя и администрирования серверов и сервисов.
Но когда случайно во время работы узнаешь, что в systemd есть свой cron, свой ntp и ещё куча своих дублированных вещей, которым опять надо заново учиться из-за чьих-то фантазий… То немного пригорает :(miga
04.12.2018 17:19+3Если у вас пригорает от того что «опять надо заново учиться», то вы, возможно, выбрали не ту профессию
skymal4ik
04.12.2018 19:50+1Нет, с профессией точно не ошибся — с удовольствием варюсь в теме, читаю хабр и другие ресурсы, смотрю вебинары, недавно вот на онлайн-курс DevOps записался :)
Но хочется изучать новые вещи, а не разбираться почему certbot использует крон от systemd, а не просто создал свое задание в /etc/cron.d/.
Вернее, даже так — мне и это интересно; ведь есть же причины, почему это создали и используют.
Но клиент ожидает [и обычно готов платить именно за это], что я просто поставлю и настрою за озвученное время инструмент. А вместо этого я вдруг узнаю что должен искать как смотреть таймеры в systemd (systemctl list-timers --all) и где редактировать таймер для certbot (/lib/systemd/system/certbot.timer).
И теперь я должен держать в голове два очень похожих инструмента, и проверять больше вещей.
А мог бы в это время почитать, например, чем firecracker лучше docker-а. Что для меня гораздо интереснее, чем изучение путей в systemd :))
Prototik
04.12.2018 19:12Из того, что там «есть свой cron» ещё не следует, что у Вас старый отобрали. Если хочется… гхм… минимализма и выпиливания лишних зависимостей — то будьте уж добры научиться, нет — используйте старый cronie (или что угодно), к которому уже прикручен юнит systemd.
skymal4ik
04.12.2018 19:58На некоторых проектах хочется стабильных, проверенных временем решений. Поставил последний Debian Stable, накатил apache+php+https и отдал клиенту.
А по факту — чтение док и выяснение почему в системе 2 крона и как редактировать задания для нового, потому что какой-то пакет стал вдруг использовать его.Ronald_Riley
05.12.2018 18:29Аааа. У нас тут админ локалхоста, который ставит апач. Ну тогда больше нет вопросов. Ты начитался на ЛОРе, что системд это плохо, но чем же плохо ты сказать не можешь, ведь фрики с ЛОРа не пишут чем плохо, а просто пишут «плохо»
powerman
03.12.2018 23:20-1Я не верю в теории заговора и поэтому полагаю, что причины были в недостатках sysvinit и прочих СИ.
Ага. Основным из которых был, конечно же, фатальный недостаток. И, кстати, я лично абсолютно уверен, что существование заговоров это факт, а не теория — это довольно очевидно. Не знаю, имел ли заговор место в случае systemd, но я бы этому не удивился, иначе довольно сложно объяснить как его сумели быстро пропихнуть почти везде, не смотря на сильное сопротивление сообщества.
Созданная в 1983 г. sysvinit не умела решать ряд важных задач, таких как:
Ну, кроме sysvinit полно других нормальных систем, например runit из простых и s6 из навороченных.
- параллельный запуск процессов;
Конечно, линукс же перегружают постоянно, скорость запуска системы — это самое главное.
- обнаружение съемных носителей;
Действительно, они ведь съёмные, поэтому их постоянно втыкают в середине процесса загрузки… нет? Странно… а почему тогда об этом должна беспокоиться система загрузки?
- активизация сервисов на основе сокетов;
Ровно так же ненадёжна, как и любой другой метод. Если сервис начал слушать порт — это вовсе не означает, что он не упадёт тут же, и в принципе будет обслуживать запросы. Это типичный пример решения несуществующей проблемы — идея неплохая, но реальной пользы от неё мало, и уж точно она не стоит той цены, включая конфликты в сообществе, которую уплатили за внедрение systemd.
- надежно контролировать зависимости между различными процессами и службами;
И снова бессмысленная фича, решающая несуществующую проблему. Да, есть начальный этап загрузки, где нужно соблюдать последовательность действий — но на этом этапе всё-равно мало смысла что-то делать одновременно. И есть следующий этап, где зависимости между сервисами не имеют значения — максимум, сэкономится секунда на перезапуске сервиса, чья зависимость не успела запуститься до него, плюс вывод одной строки в лог о причине перезапуска. Беда-беда.
- раннее логирование событий через /dev/log.
Честно говоря, я понимаю, почему логи терять нельзя. Чего я не понимаю, так это почему у меня сервис syslog (точнее, выполняющий эту роль socklog-unix) под runit запускается больше десятка лет на куче серверов одновременно со всеми остальными сервисами, без контроля зависимостей и всего такого, и никогда это не стало причиной каких-либо проблем. Ой, стойте, понимаю — systemd опять решил несуществующую проблему.
snp
04.12.2018 06:01И снова бессмысленная фича, решающая несуществующую проблему. Да, есть начальный этап загрузки
При чём тут загрузка?
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 умеет?
его сумели быстро пропихнуть почти везде, не смотря на сильное сопротивление сообщества
Потому что унифицирует кучу вещей, приводит из в порядок и сближает разные дистрибутивы. А омлет нельзя приготовить, не разбив
чьих-тояиц.powerman
04.12.2018 06:44при деплое нужно перезапустить оба сразу
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 для этих сервисов — не оказывает. Иными словами, как я уже писал — очередная бесполезная фича, классная на первый взгляд, но на практике ничего не меняющая.
snp
04.12.2018 07:33sv 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?
Конечно, всё это делается на баше, но скрипт всё растёт и растёт.
powerman
04.12.2018 15:49А потом появился 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 …mayorovp
04.12.2018 16:03Почему, собственно? Докер делает ровно то, что Вы тут описываете — запускает и перезапускает сервисы, группами, изолирует их, показывает текущее состояние, etc. И при этом он не пытается заставить нас вообще всё делать только через него.
Еще как заставляет!
Если у меня есть бинарник — я его могу запустить как демона хоть через sysvinit-скрипт, хоть через systemd-юнит, хоть через крон. Если у меня есть докер-образ — я могу запустить его только докером.
С другой стороны, если у меня есть systemd, я могу с его помощью запустить любой бинарник. Если у меня есть докер — мне надо упаковать этот бинарник в образ, для чего требуется достать базовый образ чистой системы и выяснить все зависимости бинарника.
gecube
04.12.2018 17:08Внезапно, докер можно делать from scratch… И ничего лишнего!
Это очень хорошо работает с приложениями на go, которые полностью инкапсулировано зависимости. С остальными — хуже, но тоже можно
Ronald_Riley
04.12.2018 18:47> С другой стороны, если у меня есть systemd, я могу с его помощью запустить любой бинарник.
При чем я еще могу и запускать свои контейнеры, без докера, для всяких тестов пробовал systemd-nspawn, чертовски удобная пепяка. Хотя для продакшена предпочитаю lxc для контейнеров.
gecube
04.12.2018 17:16Докер и групповой запуск?
Вы сейчас шутите?
Докер как раз ЭТУ проблему не решает.
Все равно приходится обмазываться внешними средствами: от баш скриптов и докер-компоузов до полноценных оркестраторов типа куба
И, да, докер-контейнеры можно описывать как системд юниты. Вполне себе best practice
На всякий случай поясню: пихать софт в докер — хорошая (в целом) идея. Можно контейнеры вообще на чем-то типа atomic или coreos гонять — ещё лучше. Но сам по себе он (docker) решает одну единственную задачу.powerman
04.12.2018 17:17docker swarm вполне встроенный способ это делать.
gecube
04.12.2018 17:20Это скорее про реплики, а не зависимости между сервисами.
powerman
04.12.2018 17:45Почему это? Я отлично использую swarm в рамках одного сервера, очень удобно для небольших проектов, которым нужно несколько контейнеров.
gecube
04.12.2018 22:08Ещё раз. Для нескольких контейнеров можно использовать тот же докер-компоуз. Или portainer. Или даже такое: vmware.github.io/admiral
Касательно зависимостей. Предположим, что у Вас есть набор контейнеров:
* Базы данных
* Миграции
* Тесты
* Само приложение.
Решите задачу:
* Базы должны быть запущены постоянно
* После старта баз или по триггеру от пользователя должны накатиться миграции
* После миграций — стартуют тесты
* Если тесты успешные — должны стартануть контейнеры с приложением
В рамках куба это можно красиво.
В остальном — пришлось мудрить с хелсчеками и баш обёртками.
Я уж не говорю, если пришлось бы какой-либо контейнер запускать по таймеру (крон, да?)
Ес-но не хочется оставлять контейнеры после того, как они выполнили свою функцию. Но это и ставит крест на запуске докер-компоуз с ключом --abort-on-exitpowerman
04.12.2018 23:14- Базы должны быть запущены постоянно
docker stack deploy не будет перезапускать контейнер при перевыкате сервиса, если описание конкретно этого контейнера не поменялось в новой версии сервиса.
- После старта баз или по триггеру от пользователя должны накатиться миграции
Зачем так запутанно? Миграция БД всегда связана с выпуском новой версии приложения, и накатывается в момент запуска этой версии, внутри контейнера этой версии. Можно, конечно, вынести выполнение миграции в отдельный контейнер, но это имеет смысл только если у вас разные сервисы работают с общей БД, что плохо само по себе, и вызывает кривизну в других местах вроде этого.
- После миграций — стартуют тесты
- Если тесты успешные — должны стартануть контейнеры с приложением
Какие ужасы. Я тесты гоняю на CI. А когда идёт перезапуск приложения на prod/staging то там уже никаких тестов нет, контейнеры с приложением запускаются всегда.
Итого — обёрток ноль, всё делается банальным обновлением тега образа с нашим сервисом (собранного на CI после прохождения тестов) в yml-файле описывающем стек и запуском docker stack deploy. Миграции выполняет либо сам сервис при запуске, либо shell-скрипт запускающий сервис сначала выполняет команду, которая проверяет версию схемы БД и выполняет необходимые миграции, а потом запускает сервис — да, этот двухстрочный скрипт можно гордо назвать "обвязкой", нет, никаких проблем она не создаёт.
Я уж не говорю, если пришлось бы какой-либо контейнер запускать по таймеру (крон, да?)
Да, причём не контейнер по крону, а контейнер запущенный всегда, внутри него — обычный крон-сервис, который запускает что и когда нужно.
gecube
04.12.2018 23:21Да, причём не контейнер по крону, а контейнер запущенный всегда, внутри него — обычный крон-сервис, который запускает что и когда нужно.
Уже кривизна. Почему не воспользоваться кроном на хостовой машине?
Какие ужасы. Я тесты гоняю на CI. А когда идёт перезапуск приложения на prod/staging то там уже никаких тестов нет, контейнеры с приложением запускаются всегда.
К сожалению не весь пишем мы и не весь софт из мира поней и единорогов.
Ещё раз повторю вопрос — сложные зависимости пробовали реализовывать?
Ну, судя по ответам — нет.
Вопрос «нафига они нужны» — он за скоупом нашего разговора
Кстати, systemd с этим прекрасно справляетсяpowerman
05.12.2018 00:03Почему не воспользоваться кроном на хостовой машине?
Потому, что это крон-задачи конкретного проекта, которые вполне логично запускать способом, удобным разработчикам этого проекта, включая использование привычного им крон-демона, работающего в контексте и с правами этого проекта.
Кроме того, когда этот сервис мигрирует (или масштабируется) между серверами, то намного удобнее когда абсолютно всё его хозяйство, включая настройки крона, мигрируют штатным образом — а для этого они должны быть внутри контейнера этого проекта, а не в systemd сервера, на котором он когда-то в прошлом запускался.
Ещё раз повторю вопрос — сложные зависимости пробовали реализовывать?
Не такие, как Вы описываете. Когда я сталкиваюсь с таким, то я просто переделываю это нормально — моя задача решить проблему заказчика, а не механически выполнять идиотские требования "настроить накат миграций именно таким конкретным кривым способом". По сути, когда я попадаю на новый проект, то первое, что я там делаю — настраиваю нормально CI/CD, потому что писать код без этого я уже давно разучился.
gecube
05.12.2018 00:28моя задача решить проблему заказчика, а не механически выполнять идиотские требования «настроить накат миграций именно таким конкретным кривым способом».
повторюсь — речь не про миграции как таковые. Речь про то, что докер из коробки не умеет нормальные сложные зависимости между сервисами. Решается обвязками. Можно башем. Можно systemd. Можно вообще отдельный служебный контейнер, который будет имплементировать эту логику.
когда этот сервис мигрирует (или масштабируется) между серверами, то намного удобнее когда абсолютно всё его хозяйство, включая настройки крона, мигрируют штатным образом
Дискуссионный вопрос — сколько должно быть кронов и где они должны быть (запросто, что крон джоб должен быть в единственном экземпляре). Самое верное, имхо, мигрировать в куб.
Мы действительно используем докер на standalone хостах, потому что это удобно и круто.
В других проектах — куб.
Каждой задаче — свои инструменты.
По сути, когда я попадаю на новый проект, то первое, что я там делаю — настраиваю нормально CI/CD, потому что писать код без этого я уже давно разучился.
и как это релевантно к «докер из коробки не умеет нормальные сложные зависимости между сервисами»?powerman
05.12.2018 00:46нормальные сложные зависимости
А Вы ещё не устали считать сложность — нормой? Я вот давно устал. Поэтому стараюсь делать всё как можно проще. Получается… ну, чаще получается, хотя и не всегда, к сожалению.
Когда используемый инструмент позволяет делать вещи сложно не испытывая от этого заметного дискомфорта — многие тут же радостно делают сложно… потому что для того, чтобы сделать просто — надо сначала хорошо подумать, а думать без острой необходимости многие избегают. Так что лично я предпочитаю использовать инструменты, которые не считают сложное нормой и не провоцируют делать сложно — они помогают мне находить более простые решения текущей задачи.
Конечно, возможностей простых инструментов иногда не хватает. Но я предпочитаю брать сложные не раньше, чем это произойдёт — и происходит это, на самом деле, не так уж часто.
и как это релевантно к «докер из коробки не умеет нормальные сложные зависимости между сервисами»?
Простите за вырванную из контекста цитату выше, она была нужна чтобы подготовить контекст для ответа на заданный вопрос.
Это релевантно потому, что взяв изначально более простые инструменты (runit вместо systemd, docker вместо k8s) я мотивирую себя решить задачу настройки CI/CD более простым способом, чтобы обойтись без многократно упомянутых портянок/костылей на баше. Что, в свою очередь, нередко приводит к необходимости сначала подчистить проект, как именно в нём делаются миграции, какие у него зависимости между сервисами, etc. — и, что характерно, такой подход пока что всегда шёл на пользу проекту.
ledocool
04.12.2018 15:25А в systemd нельзя громкость еще менять? А то это тоже не унифицировано — мне неудобно.
Fracta1L
04.12.2018 07:11+1я лично абсолютно уверен, что существование заговоров это факт, а не теория — это довольно очевидно
Голая вера и ничего больше. Вообще, конспирология это римейк веры в злобных демонов. Человеку проще не принимать во внимание, что другие люди могут мыслить иначе и не считать его идеи великим благом. Ему проще верить в тайных негодяев и вредителей.
скорость запуска системы — это самое главное
Может и не самое главное. Но когда в 2018 году система с многоядерным процесором и SSD грузится по 40 секунд это позорище.
бессмысленная фича
решил несуществующую проблему
Я тоже не понимаю, почему разработчики решают кучу всяких «несуществующих» проблем, ведь всем известно, что Linux существует исключительно для powerman и его задач XDpowerman
05.12.2018 00:30+1Но когда в 2018 году система с многоядерным процесором и SSD грузится по 40 секунд это позорище.
Откуда Вы взяли эту цифру? Я вот не поленился, и специально только что перегрузился несколько раз с секундомером. Мой Gentoo с runit загружается в "серверном" стиле (без X-oв и нужных только им сервисов) за 5.5 секунд. Если грузить в обычном режиме, как десктоп, то загрузка занимает примерно 40 секунд, но учтите, что сюда входят:
- 60 runit-сервисов (включая vpn, без которого упомянутые ниже браузер сотоварищи бы не запустились нормально)
- ручной ввод пароля
- запуск 20-ти терминалов, некоторые терминалы сразу с приложениями (mc, mutt, rtorrent, несколько ssh на сервера)
- pidgin, keepass, dropbox…
- и, самое главное — нескольких окон браузера с тучей вкладок в каждом
Таймер остановил глядя когда не просто все они полноценно отрисовались, но и нагрузка на CPU упала, т.е. даже браузер закончил грузиться.
Насколько лучше сделает то же самое systemd, и, самое главное, насколько это важно?
mayorovp
04.12.2018 09:00Действительно, они ведь съёмные, поэтому их постоянно втыкают в середине процесса загрузки… нет? Странно… а почему тогда об этом должна беспокоиться система загрузки?
Потому что бывают носители, которые только притворяются съёмными, но на самом деле являются системными.
Am0ralist
04.12.2018 13:32Потому что бывают носители, которые только притворяются съёмными, но на самом деле являются системными.
Кстати, а если папка с данными для загрузки такой системы находится на таком носителе, это отдельный случай или нет?
gecube
04.12.2018 14:51На самом деле для облачных хостов systemd реально выглядит оверкиллом, т.к. там весь список оборудования стандартен. И нет необходимости подключать внешние накопители и т.п.
Но с другой стороны удобно, что среда на облачных хостах и реальных серверах одинаковая. Не надо переучиваться…Ronald_Riley
04.12.2018 14:54+2Какое отношение systemd имеет к внешним накопителям? А нормальное управление сервисами нужно хоть в облаке, хоть на домашнем компе, хоть на железном сервере, нормальное управление дают юниты и никогда не давал sysV-init.
gecube
04.12.2018 15:40Ronald_Riley смотря, что Вы имеете в виду под внешним накопителем. Если это каталог, монтируемый по nfs, то его можно тоже в systemd target засунуть и обеспечить последовательность запуска сервисов. Кстати, я и не спорил, что systemd решает эту задачу. Я про другое: ОН действительно монструозен и было бы круто иметь простое решение для виртуализированных или любых других стандартизированных сред.
P.s. про внешние накопители типа usb — это к ребятам выше, они про такие «съёмные» накопители говорили
andvgal
04.12.2018 03:12+3Любители механики восстанавливают классические автомобили, любители ПО поддерживают классический init. У каждого своё хобби.
Банально нет ни одного пункта, по которому sysvinit может выиграть в надёжности и безопасности на современном сервере. Даже элементарный запуск сервиса на systemd написать проще чем через init.d, не говоря уже о контроле работы. Замена cron снимает множество проблем, а "дублированный функционал" легко отключается, если требуется более полное решение.
Упёртость отдельный коллег лишь показатель тупика, в который они себя загнали протестом.
powerman
04.12.2018 04:07На 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.serviceandvgal
04.12.2018 04:38+2Добавьте всё, что делает этот Unit в ваш пример daemontools и без костылей не обойдётесь. По факту, нужны только
ExecStartиWantedByв соответствующих разделах. Лет 10 назад daemontools был незаменим, но сейчас systemd уже на голову выше.
systemd timer активирует сервис, который запускается по расписанию со всеми гарантиями и плюшками в виде cgroups, limits, namespaces и journal. В простом cron запускается команда, которую требуется дополнительно обезопасить хотя бы от двойного запуска — это самая частая проблема.
К слову, когда-то уже упоминал, что изначально тоже был противником systemd.
powerman
04.12.2018 05:26А зачем мне всё это? Нет, серьёзно, что такого делает демон ssh на ваших серверах, чего не делает на моих? Давайте я скажу, что он делает на моих: очень надёжно запускается, и, при необходимости (мной вручную, или автоматически после падения), не менее надёжно перезапускается. А всё остальное время — просто работает. И остальные сервисы на моих серверах под runit делают ровно то же самое: они всегда гарантированно запущены и просто работают. runit позволяет очень просто настраивать их запуск (примеры выше), удобно смотреть их текущее состояние, запускать/перезапускать/останавливать. Плюс, важная фишка, не менее надёжно, качественно, удобно и единообразно вести логи всех сервисов через svlogd — с фильтрацией, ротацией, etc. … и даже, Вы не поверите, в текстовом формате! :)
Я никогда не спорил с тем, что у systemd намного больше фич… я высказывал обоснованное сомнение в нужности и полезности этих фич, а так же в том, что они окупают недостатки systemd.
Crandel
05.12.2018 12:32+2Системд позволяет легко прописывать зависимости. Банальный пример — сервер запускается после старта сети.
А еще мне баш совершенно не понятен, я питоном и джавой балуюсь. Вот системд позволит в легкую мне настроить все что нужно для работы моих сервисов, без надобности дебажить(через echo) портянку баш скриптов. Да я знаю, что на нем даже игры пишут, но для меня это какой-то брейнфак и мне не хочется тратить время на его изучение.
- /etc/service/ssh/run:
PerlPower
04.12.2018 06:05Не понимаю почему нельзя было оставить systemv как основную систему инициализации, а systemd как опцию для тех кому она нужна. Для одноразовых скриптов systemv мне была удобнее, потому что нужно было бороться только со скриптом, а не с целой системой инициализации. Systemd вообще никаким образом не помогает от сдохших сервисов, для этого вообще-то специальные системы мониторинга есть. Иногда она их перезапускает, иногда нет(хотя может у меня руки кривые). Наверное даже для случаев когда сервис висит на порту но не реагирует есть у systemd какой-то костыль, но по сути это будет тот же мониторящий скрипт через обертку systemd.
Замыкать фичи десктопных сред на систему инициализации от которой может быть польза только матерым админам это вообще сильно. И как вишенка на торте — не все авторы софта или ментейнеры дистров сами хорошо разбираются в systemd, в итоге приходится переписывать юниты самому.
Наверное профессиональным администраторам linux стало легче с появлением systemd, но почему нельзя было сделать ее такой же опцией как и selinux, который тоже системе в кишки залезает, но пока его не поставишь, все работает и без него?snp
04.12.2018 08:13+3что нужно было бороться только со скриптом, а не с целой системой инициализации
С чем конкретно вам бороться нужно было? Вот минимально необходимый unit, чтобы сервис работал (причём, если не надо его запускать после ребута автоматом, то достаточно 2 первые строки):
[Service] ExecStart=/bin/sleep 100 [Install] WantedBy=multi-user.target
Вы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?
Systemd вообще никаким образом не помогает от сдохших сервисов
Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.
фичи десктопных сред на систему инициализации
Какие конкретно?
не все авторы софта или ментейнеры дистров сами хорошо разбираются в systemd
Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.
но пока его не поставишь, все работает и без него?
Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?
surefire
04.12.2018 08:56+1А если процесс подвис
Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET.
PerlPower
06.12.2018 11:16Насколько я понял это работает только в случае, если в сервисе уже есть механизм для отсылки нотиса вотчдогу. Т.е. скорее всего придется опять писать старый добрый шелл скрипт, которые бы хитро следил за процессом и посылал уведомления?
surefire
06.12.2018 11:55+1Да, я именно так и написал
единственное, что требуется от сервиса, уметь периодически слать sd_notify
Придется накостылять скрипт или просить разработчиков сервиса добавить такую функциональность. Ведь по другому никак не узнать именно о зависании. Вообще systemd не запрещает писать скрипты и не думаю, что для фанов sysvinit это проблема. Тем более, если такая функциональность уже была в sysvinit скрипте, то останется добавить только одну строчку с вызовом
systemd-notify
snp
06.12.2018 14:22Скрипт не поможет, потому что отсылать должен $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
PerlPower
06.12.2018 11:05-3Вы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?
#!/bin/sh /bin/sleep 100
И положить в нужный мне rc.* Поймите, я не профессиональный админ, и мне это правда проще, чем читать документацию по systemd и всем ее возможностям.
Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.
А не логичней ли, если вам правда нужно чтобы сервис гарантировано жил, использовать таки полновесную систему мониторинга, а не штуку, которая иногда рестартит, иногда нет?
Какие конкретно?
В статье ищите по слову Gnome.
Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.
Самое смешное забыл, до сих пор куча юнитов — это просто обертка над теми нелюбимыми вами shell скриптами. Потому что нельзя всегда всю логику инициализации сервиса запихнуть в однострочную команду. Т.е. был просто добавлен слой асбтракции и все, по сути ничего не изменилось — шеловая портянка никуда не исчезла.
Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?
Проблема в том, что мне рядовому пользователю линукса на десктопе и веб-макаке по совмсестительству никакой пользы от systemd нет. Проблема в том, что завязывать целые пользовательские среды на systemd это странно, потому что помимо линукса есть есть *bsd, солярка, и все тот же линукс, но без systemd.gecube
06.12.2018 11:14+1А не логичней ли, если вам правда нужно чтобы сервис гарантировано жил, использовать таки полновесную систему мониторинга, а не штуку, которая иногда рестартит, иногда нет?
systemd реализует примерно аналогичные примитивы по мониторингу сервисов как и докер. И ничего — никто не жалуется. На самом деле, это правильный подход. Потому что то, что было раньше — с теми же PID-файлами — это тихий ужас. Я даже более того скажу — был у меня случай в практике, когда PID-файл сервиса был создан, в нем был записан PID. Сервис тихо сдох никого не уведомив, а другая приложуха этот PID захватила. Естественно, что после этого сервис было невозможно перезапустить штатно ))))
Проблема в том, что завязывать целые пользовательские среды на systemd это странно, потому что помимо линукса есть есть *bsd, солярка, и все тот же линукс, но без systemd.
проблема в том, что в КАЖДОЙ системе свой вариант системы инициализации. Буквально где-то в соседних комментах об этом говорилось.
mayorovp
06.12.2018 11:18+2Нее,
/bin/sleep 100писать в rc.* нельзя. Как минимум, должно быть/bin/sleep 100 &. А еще нужно проверить первый аргумент, который может быть одним из вот этого списка: start, stop, restart, status, poll, enabled, rcvar...
amarao
04.12.2018 16:00+2Для начала нет «systemv» — это вы что придумали. Наверное, речь про sysv-init. systemd отлично умеет перезапускать, придерживать перезапуск и обрабатывать падения сервисов.
Более того, systemd — единственный из всех инициализаторов, который может при завершении (stop) гарантировано прибить всё, что нафоркал демон. Ни upstart, ни sysv-init физически не имеют возможности трекать потомков.PerlPower
06.12.2018 11:12Лично у меня openvpn падал без воскрешения, хотя иногда systemd его таки перезапускал, иногда нет. Я не знаю что это было — баг в openvpn, баг в конкретной версии systemd или мои кривые руки, но впечатление осталось. В итоге написал свой шелл скрипт, который мониторил по крону.
snp
06.12.2018 14:36+1падал без воскрешения, хотя иногда systemd его таки перезапускал
Потому что «проверенную временем» схему с форком и уходом в background надо безжалостно выпиливать везде где только можно. В случае с openvpn это опция
daemon(её найти и удалить).
В вашем случае, скорее всего, openvpn форкался и в таком случае systemd может и не отследить, что сервис упал.
worldmind
04.12.2018 12:48+2Во-первых, зрячий увидит, что при голосовании в дебиане конкуренция шла между systemd и upstart, старьё никто не хотел оставлять.
Во-вторых, вроде systemd никак философии юникс не противоречит, это множество маленьких демонов взаимодействующих между собой через единый интерфейс, детали отличаются, но суть вроде та же, я глубоко не копал, поправьте если ошибаюсь.
В-третьих, бинарность логов это никакая не проблема, а фича, которая даёт многое, например возможность индексирования, какая вам разница как храниться лог? В текст он легко превращается. Те же рассуждения и о бинарности протокола.
Ну и переход от написания скриптов к конфигам (unit файлам), это просто шаг в будущее, в первую очередь по причине безопасности, ну и читаемость выше за счёт унификации формата.
Ironhide
04.12.2018 13:24В общем опять каждый на себя одеяло тянет. Но нам, пользователям, не привыкать…
sevikl
04.12.2018 13:30«Сложный» systemd только тем, что он другой. если потратить немного времени на адаптацию (а это занимает реально меньше времени, чем баттхёрт в интернете) — он ничем не сложнее, чем то, чем вы там пользовались до этого. и уж фишечки с параллельностью, контролем за перезапуском, множественные инстансы и т.п. это серьезные плюсы.
Ronald_Riley
04.12.2018 13:47Когда я вижу рассуждения, что якобы 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).gecube
04.12.2018 15:36+1Офигенная крутость решения systemd, что мы действительно перешли от кода (init скрипты) на конфигурационные файлы (каковыми и юниты несомненно являются). А дальше — легко их версионировать, хранить, выкладывать. Стоимость обслуживания падает, т.к. разбираться в портянках ьашей — это реально надо быть спецом. Сплошные плюсы.
Минусы в том, что помимо systemd unit'ов иногда удобно хранить настройки в дефолтных файлах конфигов. Ну, и некоторые юниты от разработчиков сервисов ущербные. Взять ту же монгу. Выглядит очень мерзко, когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл. Решение? Общего не нашел, но можно делать свой юнит и класть его рядом со «штатным». Главное — потом не забыть, что там админ/разработчик понаписал.snp
04.12.2018 15:47+1Ну, и некоторые юниты от разработчиков сервисов ущербные.
Ну да, например в
mongod.serviceуказаноType=forking, однако надо при первой же возможности от форка избавляться. Монга сама умеет в foreground стартовать.
когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл.
А вы, надеюсь, правите не в
/lib/systemd/system? Надо это делать в/etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.
Решение? Общего не нашел,
Например,
systemctl mask some.serviceи делаем свой unit с немного другим именем.gecube
04.12.2018 17:14А вы, надеюсь, правите не в /lib/systemd/system? Надо это делать в /etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.
Спасибо за напоминание, Но вообще вопросы раскладки чего-либо по файловой системе всегда были дискуссионными. Тем более, когда используешь несколько разных дистрибов (ub/deb vs rhel/centos)snp
04.12.2018 17:30В случае systemd есть стандартное соглашение по директориям, их функциям и приоритету. См. systemd.unit(5)
mayorovp
04.12.2018 15:48Так ведь юниты из пакетов и юниты написанные админом лежат в разных директориях, причем при совпадении имен вторые перекрывают первые…
Как монга в таких условиях может переписать исправленный файл? Это точно минус systemd?gecube
04.12.2018 17:12Ещё раз — я системд и не ругаю особо. Просто есть некоторые особенности работы с ней, которые нужно иметь в виду. А идеальный вариант — чтобы они сразу бросались в глаза, а не после ХХ часов опыта с этой штукой. Это тоже привело к тому, что мейнтейнеры стали бы писать нормальные юниты (а не как сейчас).
Ronald_Riley
04.12.2018 17:06+1По поводу юнитов от разработчиков… Разобраться в юните все равно всегда проще, чем читать простыню которую кто-то левой задней ногой писал то ли на пуре-шелл, то ли на баше, то ли еще на каком диалекте.
Как правильно отметили ниже юниты из пакета должны идти в /lib/systemd/system, а твои личные в /etc/systemd/system и те которые из /etc/systemd/system при наличии одноименных в /lib/systemd/system имеют приоритет. Так что выход складывать свои на место, куда положено. А если мэйнтейнер складывает свои не туда, то бить ему по рукам.Fracta1L
05.12.2018 10:10+3Добавлю ещё, что необязательно полностью копировать мантейнерский юнит ради одной правки, можно просто объединять их через .include, например:
.include /usr/lib/systemd/system/httpd.service
[Service]
CPUShares=500
Prototik
04.12.2018 19:19+1systemctl edit mongoи редактируйте до посинения. При этом всё будет обновляться с сохранением изменений и бла-бла-бла.
ledocool
04.12.2018 15:07-1Леннарт Поттеринг может быть хорошим программистом
В каком месте он хороший программист, если он даже философию сообщества не осилил?
amarao
04.12.2018 15:55+1Не передёргивайте. sysv-init вообще занимался сервисами. Он занимался парсингом /etc/inittab и перезапуском того, что там написано.
А вот всё остальное — включая команду service и т.д. — это уже система инициализации, написанная на баше. Я бы сказал, что в этом месте её надо закапывать, но нет, на баше написана не только система, но и её файлы конфигурации. /etc/rc.d/foo — это не конфиг, это скрипт. Который при этом конфиг. Но тьюринг-полный. Мы все любим тьюринг-полные файлы конфигурации на bash.
amarao
04.12.2018 15:57Да, ещё. Я могу понять причины сохранения sysv-init'а, но причин терпеть upstart никаких — кривая поделка с массой глюков и wtf, которую каноникал писала в своём стиле (стиле гугла?) — написать и закопать.
Evengard
Может быть конечно systemd и монстр, но unit-файлы это удобно, и возвращаться на громоздкость sysvinit как-то совсем не хочется.
gecube
Поддержу. А upstart редкое… уродство. Я пробовал воевать с upstart и просто счастлив, что убунт овцы одумались и выпилили его в 16.04 в пользу systemd.
dmitryredkin
А я вот типичный админ локалхоста, и с переходом на systemd у меня появилось столько проблем, что я бы с радостью засунул эту systemd в… короче, далеко.
До сих пор не смог до конца разобраться, почему некоторые сервисы не стартуют, правила iptables то работают, то нет, saned вот вдруг отвалился, приходится сканировать через scanimage.
До этого 10 лет все работало, пережило кучу апгрейдов, а тут вдруг перестало…