systemd десять лет спустя. Историческая и техническая ретроспектива

    Десять лет назад был анонсирован systemd, который устроил революцию в управлении системой дистрибутивов Linux, тем самым разделив пользователей Linux на несколько лагерей. Качество и природа дебатов не сильно улучшилась со времён пламенных войн 2012-2014 годов, и systemd всё ещё остаётся не до конца понятым и изученным инструментом и с технической, и с общественной стороны, несмотря на пристальное внимание к нему сообщества.

    Это пост не совсем о том, как пользоваться systemd. Тут, скорее, будет говориться об истории его возникновения, о его компонентах в целом, и о том, как понять систему, которая начиналось как просто PID 1 и стала тем, что я бы назвал middleware современного дистрибутива Linux.

    А может, это просто набор крайне вольных переводов различных материалов с блогов, каналов и статей на Arch wiki. Вам решать.

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

    Но прежде чем начать речь о systemd, хочу рассказать об init.

    init


    В седьмом издании UNIX (1979) задача init — это выполнить при старте /etc/rc и создавать процессы инициализации терминала (getty) и логина (login).

    Затем постепенно добавлялись новые задачи. Например, перехват ничейных процессов. Или очистка каталога /tmp. Или монтирование файловых систем.

    Так, сегодня основная задача init — привести систему из состояния «ядро запущено» к «система готова к работе». Запустить userspace, другими словами.

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

    И /etc/rc со скриптами, конечно, могут запустить всё, что нужно, но что, если, скажем, надо просто перезапустить какой-то демон? Вышедший в 1983-м UNIX System V, который ввёл понятие runlevel, или уровень выполнения, частично решал эту проблему и позволял таким образом управлять целыми группами демонов.

    Linux перенял у UNIX интерфейс инициализации (sysvinit), и в целом, всех всё устраивало, но тем не менее, были пользователи, которых sysvinit стеснял. Так, Matthias S. Brinkmann однажды написал в своём блоге заметку «Почему sysvinit — отстой». Оригинал удалён, поскольку, по мнению Матьяса «sysvinit уже мёртв», но вольно переведу вкратце найденную в интернете перепечатку:

    • Если у вас нет чёрного пояса в микадо, вы быстро потеряетесь в инсталляции sysvinit. Большинство скриптов имеет, по крайней мере, три репрезентации на диске: скрипт, симлинк запуска и симлинк остановки.
    • Надо самостоятельно настраивать порядок запуска сервисов. Для всех. Без исключений. Но серьёзно, какая разница, что запускается раньше — инициализация клавиатуры или системные часы? Если вы хотите это контролировать, то ладно, но SysVinit принуждает вас к контролю всего.
    • Нет управления зависимостями. Да, можно дать скрипту номер 100, а его завиимости — 99, но иногда этого недостаточно. Что, если сервис B требует сервис A в запущенном состоянии, а тот упал после запуска? SysVinit всё равно запустит сервис B! Таким образом, вы рискуете получить систему, где что-то провалилось, скажем, файловая система не примонтировалась и от этого часть системы отвалилась, но программа SysVinit runlevel весело отрапортует, что всё запущено, и у вас есть X сервер с сетью.
    • Его тяжело редактировать: иначе зачем люди пишут красивые GUI для автоматизации добавления-удаления скриптов из уровней выполнения? Потому что вручную управлять дюжиной симлинков, где каждая опечатка может привести к сломанной системе, это безумие.
    • Он плохо масштабируется. Взгляните на Linux From Scratch: он использует три числа для обозначения последовательности запуска. Говорит о многом про систему с только десятком загрузочных скриптов, не так ли? Проблема в том, что когда вам надо добавить новый скрипт, его надо уместить в последовательность загрузки и, возможно, переиндексировать все скрипты инициализации. Вообще, это напоминает мне о временах BASIC с номерами строк, когда надо было уместить больше девяти строк между строкой N и строкой N+10. К счастью, в BASIC есть команда renum. А в SysVinit, конечно, вы сами можете написать скрипт, который сделает переупорядочивание за вас. Админы SysVinit любят упражнения.
    • Он не очень уживается в автоматических инсталляциях и системах, где пакеты поставляются со своими загрузочными скриптами. Допустим, пользователь создал свой загрузочный скрипт с номером N. А потом решил поставить пакет FTP-сервера, который идёт со своим скриптом с тем же номером. Привет, конфликт.
    • В SysVinit невозможно тестировать изменения. Чтобы протестировать последовательность загрузки SysVinit и выполнение уровней, надо выполнять потенциально опасные команды. Иногда требуется несколько циклов перезагрузки, прежде чем всё заработает.
    • Небезопасный шатдаун. SysVinit полагается исключительно на загрузочные скрипты, чтобы отмонтировать файловые системы и остановить процессы. Это крайне небезопасно и может вылиться в потерю данных в худших случаях.

    Позже, разработчик Busybox Денис Власенко опубликовал в своём блоге запись SysV init must die, и, несмотря на то, что сразу делается оговорка, что это шутка, да и вообще пост сделан в формате диалога, а не конфликта, претензии к системе были.

    Подытоживая, sysvinit был разработан больше 30 лет назад со старыми концепциями, которые уже не решали задачи XXI века. Мало того, система не развивалась и не вводила новые идеи.

    В атмосфере беспорядочного хаоса было предприняты несколько попыток решить проблемы sysvinit:


    Но на сегодня самой известной альтернативой (кроме systemd) является, пожалуй, Upstart.

    Upstart


    Часть проблем sysvinit вызвался решить Upstart (также известный как ReplacementInit), альтернативная система инициализации, выпущенная в 2006-м году Canonical, разработчиками Ubuntu. Его главная концепция — event-driven подход. Запуск системы — это событие, новое устройство — событие, запуск демона — событие. Процессы могли подписываться на события и запускаться только при явной необходимости.

    Upstart совместим с sysvinit-скриптами, благодаря этому он был быстро интегрирован во многие дистрибутивы Linux. Тем не менее, после того, как большинство дистрибутивов Linux по тем или иным причинам перешли на systemd, разработка сошла на нет: последний релиз был в 2014-м году, и сегодня Upstart используется только в Chrome OS.

    Новый init


    «we are experimenting with a new init system and it is fun»

    Весной 2010 года в блоге Леннарта Поттеринга вышел материал Rethinking PID 1, в которой он описал своё видение эффективной системы инициализации.

    По его мнению, эффективный init должен обладать следующими характеристиками:

    • Запускать меньше демонов. Точнее говоря, запускать только то, что требуется: подключили сеть — включаем сетевые демоны, зашёл пользователь — включаем его персональные демоны, и так далее.
    • Запускать ещё меньше демонов! Что, если не запускать sshd сразу, а начинать «слушать» TCP-сокет вместо него и при первом подключении запускать sshd, передавая ему дескриптор сокета.
    • Запускать больше демонов параллельно. Например, какая разница, кого запускать первым — sshd, cupsd или httpd, если можно запустить все вместе?
    • Быть динамичным. init должен реагировать на изменения как в демонах, так и в «железе», и запускать (и иногда останавливать) соответствущие службы.

    В то же время Поттеринг подчёркивает, что эти идеи не новые, и уже известна система с такими возможностями — launchd от Apple, система инициализации в macOS. launchd имеет схожие с Upstart event-driven идеи, но более того, он вобрал в себя задачи других системных сервисов, таких, как cron и inetd.

    Другая идея, которую можно почерпнуть из процесса загрузки macOS: shell-скрипты — это зло. Их легко написать, но трудно поддерживать, и они медленно выполняются: каждый вызов grep/awk/sed/cut в одном скрипте — это запуск процесса, подгрузка его библиотек, операции типа локализации вывода, и так далее. И так с каждым init-скриптом. В контексте запуска системы выполнение множества консольных команд тормозит весь процесс.

    «Так давайте избавимся от shell-скриптов в загрузке!» — воскликнул Леннарт. «Большая часть init-скриптинга сводится к тривиальному запуску-остановке демонов, и эту логику можно переписать на C и поместить или в отдельные исполняемые файлы, или в сами демоны, или просто в init».

    Другие возможности, которыми должен обладать хороший, по мнению Поттеринга, PID 1:

    • Распараллеливание задач файловых систем. Проверка на ошибки, монтирование и квотирование. Что, если монтировать файловые системы одновременно, или только при доступе к ним?
    • Отслеживание процессов. Одна из задач системы управления сервисами — это мониторинг процессов. Перезапускать, если они упали. Собрать информацию, если они крашнулись. Кроме того, система должна уметь останавливать сервисы, что может быть непросто, если процесс сделал двойной вызов fork().
    • Управление ресурсами сервисов. В идеале, init должен настроить окружение updatedb (обновление БД команды locate) так, чтобы процесс выполнялся только при полном бездействии.
    • Логирование также является важной частью выполнения сервисов. Несмотря на то, что логи — сложная штука, простые сценарии типа вывода в stdout/stderr или обработка логов ядра (dmesg) должны решаться компонентами init.

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

    Почему бы просто не добавить всё это в Upstart, зачем изобретать по-новому? Или почему бы не портировать launchd? Ответ прост — на взгляд Леннарта, у Upstart, несмотря на event-driven подход, есть недостатки в архитектуре и дизайне. А launchd вряд ли хорошо прижился бы в Linux.

    systemd


    Анонсированный в Rethinking PID 1 прототип systemd, ранее известный как "BabyKit" (от process babysitter — нянька процессов), быстро получил доминирующий статус благодаря своей лёгкости.

    Сегодня на странице проекта говорится уже не про PID 1, а про комплект базовых блоков для системы Linux.

    Что под этим скрывается? systemd теперь называется конструктор из компонентов, каждый из которых отвечает за свою задачу, связанную с сервисами или системой в целом.

    systemd — это система управления системой. Он берёт и объединяет в системный слой подсистемы, которые, с одной стороны, не забота ядра, а с другой — пользователю они редко интересны.

    Восход к власти


    Разработчики systemd не теряли времени на проповедование. Несмотря на пятна от помидоров в списке рассылки fedora-devel, systemd в июле 2010 года стал стандартом инициализации в Fedora Rawhide.

    В обсуждениях разработки Fedora, связанных с systemd, Леннарт занимал боевую позицию, особенно в вопросах обратной совместимости: так, отвечая на беспокойства Мэтью Миллера касательно совместимости с inittab, он спрашивал: «Может, мы должны проверять ещё и AUTOEXEC.BAT?… Да, давайте снова вернёмся к теме inittab. Это было так весело!». Когда его спросили про необходимости исправлять пакеты из-за нововведений systemd, он ответил: «Круто, полагаю, теперь я стану разработчиком X (X-сервера).

    Вероятно, если KMS сломан, мой долг — исправить это. Ура!»

    Всё обсуждение демонстрировало в чём-то инфантильный недостаток внимания Леннарта к ситуации, в которой многие пакеты и подсистемы перед релизом Fedora 14 нужно было подготовить к работе с systemd. Естественно, эта мыльная опера появилась на LWN.

    Как бы то ни было, амбиций у Леннарта было полно. В июле 2010 он был уверен, что дистрибутивы возьмут к себе systemd:

    7) Перейдут ли другие дистрибутивы на systemd?
    Ну, не так быстро, как Fedora, но похоже на то.

    А в сентябре 2010 он чётко заявил кросс-дистрибутивную интеграцию как одну из целей systemd:

    Мы намерены мягко подталкивать дистрибутивы в одном направлении, чтобы они прекратили поддерживать другие решения ...

    В августе 2012 года Arch Linux переключился на systemd, хоть и с небольшой драмой.

    Немного позже, в октябре того же года, благодаря упорству Леннарта, GNOME перешёл на systemd-logind. В октябре 2019 вышел GNOME 3.34 полностью интегрированный с systemd.

    На момент 2013 и 2014 годов Debian и Ubuntu были последними, среди ведущих дистрибутивов, не принявших systemd.

    Josselin Mouette в октябре 2013, будучи мейнтейнером пакета GNOME в Debian, заявил в списке рассылки Debian следующее:

    systemd становится де-факто стандартом в дистрибутивах Linux (по крайней мере в Fedora, SuSE и Arch) и получает превосходную поддержку во множестве пакетов. До сих пор только Gentoo использует OpenRC, и только Ubuntu использует Upstart. Поэтому использование OpenRC бы означало необходимость в поддержке множества собственных патчей, а использование Upstart бы значило, что мы становимся апстримом Ubuntu.

    … Завершая, я скажу как мейнтейнер пакета GNOME. GNOME-у в Jessie понадобится systemd как система инициализации для работы всего функционала так же, как ему требуется NetworkManager для работы конфигурирования сети.


    Более того, в декабре 2013, в изложении ситуации с init в Debian за авторством Расса Олбери, в разделе «3.1. Реальность экосистемы», сказал, что разговор идёт уже не о «systemd-против-альтернатив», а о «как-много-будет-systemd»:

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

    Другими словами, это дебат не о systemd против upstart в обычном смысле. Вопрос, скорее, в том, принимаем ли мы systemd со всеми его составляющими, включая систему инициализации, или же мы берём его подсистемы, но в качестве системы инициализации выбираем upstart. В любом случае, будет работать udev, logind, timedated и другие службы.

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


    Это и произошло. Debian Jessie вышла с systemd в качестве менеджера системы, и вслед за Debian systemd был включён в Ubuntu 15.04.

    По правда говоря, это пост не о войнах systemd. Если хотите почитать ещё, но лень копаться в списках рассылки, то держите чей-то материал, который отчасти вдохновил меня на этот пост.

    Компоненты systemd


    System manager


    systemd как менеджер системы вводит в систему множество концепций, и основная — это юнит. Юнит является абстрактной сущностью, которая содержит имя, описание и те или иные завимости.

    Под каждым юнитом скрывается конфигурационный файл, во многом похожий на Windows .ini файлы.

    На момент systemd 234 юниты делятся на 13 типов, вкратце:

    • service. Содержит набор команд и настроек, необходимых для работы демона. Или не демона — в сервисе можно запускать и короткоживущие команды или скрипты. Типичный пример сервиса — sshd.service, демон ssh. Интересный факт: сервисы можно запустить без определения текстового файла через systemd-run.
    • target. Аналог runlevel в sysvinit. Некая точка в жизненном цикле системы, к которой могут «цепляться» другие юниты.
    • timer. С некоторым интервалом запускает связанный с ним юнит. Аналог задач в cron, однако с поддержкой гораздо более богатого синтаксиса правил дат, который можно посмотреть в man systemd.time.
    • mount. Аналог записи в /etc/fstab, даже более того — systemd самостоятельно парсит fstab и динамически создаёт на его основе юнит-файлы. Так, например, через systemctl cat -- -.mount можно увидеть, какой юнит-файл создаётся для корневого раздела.
    • automount. То же самое, что и mount, только монтируется «лениво», при первом доступе.
    • socket. Позволяет запустить связанный с ним сервис отложенно: systemd при запуске сети начинает слушать сокет, а при первом пакете или подключении запускает сервис, передавая ему объект сокета. Требует дополнительной доработки в сервисе (интеграции с libsystemd или с systemd-socket-proxyd).
    • path. Запускает связанный с ним юнит при доступе или изменения пути, будь то файл или каталог.
    • swap. Особый вариант mount, содержит информацию о файле или разделе, выделенный под swap.
    • slice. Концепция подсистемы управления ресурсами systemd. Подробнее можно почитать в посте Red Hat.
    • scope. Внутренняя часть systemd. Этот юнит создаётся при запуске сервиса и используется для объединения процессов в группы и управления ресурсами сервиса.
    • snapshot. У этого юнита, как и у scope, нет конфигурационного файла, он создаётся динамически при выполнении команды systemctl snapshot. Созданный «снимок» будет содержать статус всех юнитов на данный момент, впоследствии на него можно «откатиться» командой systemctl isolate после запуска/остановки сервисов и других юнитов.
    • device. Юнит устройства, такого, как блочное или сетевого устройство. Тесно связан с sysfs/systemd-udevd.
    • nspawn. Юнит systemd-контейнера, о которых чуть позже.

    Повторюсь, что каждый юнит содержит секцию зависимостей. Так, сервис может зависеть от статуса target, таргет, в свою очередь, от другого таргета, ещё один сервис может зависеть от таймера, тот — от таргета, и так далее.

    journald


    Пожалуй, одна из самых популярных частей systemd. В journalctl можно посмотреть всё, что произошло с системой: логи sshd, логи ядра и его драйверов, сообщения о крахах, и многое другое.

    История journald: syslog

    Долгое время важным компонентом любого дистрибутива Linux был демон syslog. На протяжении истории было сделано множество реализаций интерфейса syslog, но в целом они были реализованы схожим образом и использовали почти один формат данных на файловой системе.

    Целью демона syslog является, как понятно из названия, логирование процессов системы. Демон получает от приложений и сервисов сообщения в относительно свободной форме и сохраняет их на диске. Как правило, единственные метаданные сообщения — это facility (примеры: ядро, почта, сеть, и т.д.) и приоритет, а также timestamp, тег процесса и его PID. Большинство этих полей опционально, и точный синтаксис варьируется от реализации к реализации.

    syslog не принуждает заполнять все поля, что делает его лёгким в использовании и в то же время мощным в плане расширяемости. В то же время, это его изъян — syslog имеет на руках некоторый беспорядок без строгого формата, и такой результат трудно парсить.

    Система syslog уже 30 лет (на момент появления journald), благодаря своей простоте, является незаменимым инструментом администраторов. Однако число ограничений солидно, и со временем они стали заметными проблемами:

    1. В целом, данные сообщений не проходят аутентификацию: любой локальный процесс может заявить, что он Apache с PID 4711, и syslog поверит ему.
    2. Данные записываются в вольном формате. Анализаторы логов должны парсить человеческий язык, чтобы a) опознать тип сообщения, и b) извлечь из него параметры. Это выливается в т.н. «regex horrors» и многие другие неприятные последствия, в том числе для разработчиков программ, которые пишут эти самые логи.
    3. Временные метки не обязаны содержать информацию о временной зоне, даже при том, что новые спецификации дают возможность их передавать.
    4. syslog, хоть и является стандартом, лишь одна из многих систем логирования. Отдельные логи держат utmp/wtmp, lastlog, audit, ядро, логи прошивок, и много других подсистем и приложений.
    5. Чтение логов простое, но крайне неэффективное. Большинство операций с логами имеет сложность O(n). Индексация невозможна.
    6. Сетевой протокол syslog простой, но также крайне ограниченный. Он поддерживает только push-модель, и не применяет модель хранения-передачи, что вытекает в проблемы типа Thundering Herd или потери данных, которые затрудняют использование syslog.
    7. Контроль доступа отсутствует как таковой. Если отставить в сторону всякий скриптинг, администратор может дать пользователю или полный доступ, или ничего.
    8. Автоматическая ротация логов есть, но далека от идеала в большинстве реализаций. Вместо того, чтобы непрерывно мониторить использование диска и реагировать на заполнение, ротация происходит лишь через некоторые интервалы времени. Что открывает дорогу различным DoS-атакам.
    9. Ограничение пропускной способности (rate limit) есть в некоторых реализациях, однако в целом использование диска не учитывается.
    10. Сжатие структуры логов на диске, в целом, присутствует, но, как правило, это просто эффект ротации и ничего хорошего в плане производительности поиска не даёт.
    11. Классический syslog бесполезен в сценариях логирования запуска или остановки системы, впрочем, последние улучшения (в т.ч. и в systemd) улучшили положение дел.
    12. Нельзя логировать бинарные данные, что может быть необходимо в некоторых сценариях (дампы прошивок, блобы ATA SMART или SCSI)

    С целью решить эти проблемы и был представлен journald:

    1. Сообщения проходят аутентификацию. Кроме того, метаданные вроде PID или команды процесса journald добавляет самостоятельно, у процесса нет возможности представиться кем-то другим.
    2. Данные структурированы: запись журнала состоит из key-value полей, что упрощает их последующую обработку.
    3. Временные метки состоят из монотонного времени и realtime времени, причём realtime метки хранятся в наносекундах с UNIX epoch в UTC, чтобы избежать проблем с таймзонами.
    4. Функционал journald достаточно универсален, чтобы решить большинство сценариев логирования демонов и приложений.
    5. Журналы хранятся в бинарном виде. Это упрощает хранение, ротацию и индексацию.
    6. Сетевой протокол journald сделан с оглядкой на огрехи существующих систем.
    7. Файлы журналов разделены по пользователям и у каждого свои права доступа. Так, обычный пользователь имеет доступ к логам своих процессов, и не может открыть журнал системы.
    8. Журналы ротируются автоматически при превышении определённых пределов использования места.
    9. По умолчанию логи процессов, которые пишут, скажем, гигабайты отладочных сообщений, подвергаются rate limit-у. При этом делается это аккуратно и исходя из ресурсов файловой системы, оставляя при возможности сообщения с более высоким уровнем.
    10. Данные сжимаются по полям, это обеспечивает хорошие показатели компрессии.
    11. Одна из идей journald — это объединить все различные технологии логирования, такие, как wtmp, логгеры загрузки, логи ядра, и даже логи подсистемы аудита.
    12. Несмотря на то, что основной фокус сделан на ASCII-сообщения в логах, бинарные данные в полях тоже поддерживаются.

    О journald

    Базовая интеграция с journald элементарна: процессу достаточно писать в stdout/stderr, а дальше подсистема сама разберётся, какой это сервис, сессия пользователя, исполняемая команда и прочие атрибуты.

    Для более тесной интеграции понадобится использовать библиотеки: так, например, для Python есть модуль pystemd.journal библиотеки pystemd.

    Подробнее про то, как работать с journald, можно узнать из поста Selectel и в man journalctl.

    Документ за авторством Леннарта с описанием journald и его тонкостей можно почитать тут.

    machined


    systemd-machined — часть systemd-nspawn, платформы контейнеров systemd. По концепции контейнеры systemd далеки от, скажем, Docker: когда как Docker — прежде всего, платформа stateless контейнеров, systemd-nspawn является просто способом запустить systemd в stateful контейнере. nspawn гораздо проще Docker: тут нет REST API, нет labels, нет управления сетями, volume и прочим. С одной стороны, это минус контейнеров systemd, с другой — они подойдут тем, кто привык настраивать сеть и окружение самостоятельно.

    Главное преимущество systemd-nspawn — это тесная интеграция с экосистемой systemd. Для каждого контейнера создаётся слайс и сервис, ресурсы можно настроить через systemctl set-property, и внутри контейнера systemd работает без проблем.

    Подробнее о systemd-nspawn можно почитать на Arch wiki или в посте Selectel.

    Другие известные компоненты


    • coredump. systemd-coredump перехватывает крахи процессов и записывает их дампы памяти в свою базу для дальнейшего анализа.
    • logind. systemd-logind управляет жизненным циклом пользователей и их сессиями: создаёт slice под каждого пользователя, запускает getty для логина из консоли, обрабатывает кнопки включения-выключения системы, и прочее.
    • udevd. Отвечает за аппаратную часть системы в userspace: названия сетевых интерфейсов и блочных устройств.
    • hostnamed. Крохотный демон, который отвечает за предоставление имени системы и связанных с системой данных (тип корпуса, ОС, архитектура и т.д.) другим приложениям.
    • timedated и timesyncd управляют настройками, связанными со временем: датой-временем системы, временной зоной, переводом времени и прочим.
    • localed занимается такими параметрами, как язык системы и раскладка клавиатуры.
    • networkd и resolved. Неплохая альтернатива NetworkManager и dnsmasq в сценариях, когда их функционал избыточен.
    • systemd-boot. Простой загрузчик ОС, принципиально совместимый только с UEFI.
    • systemd-homed. Принципиально новый подход к управлению домашними каталогами, настолько новый, что кроме статьи в Arch wiki ничего по нему найти не смог.

    Мифы о systemd


    systemd монолитен

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

    Комплект из почти сотни бинарников назвать монолитным непросто. Впрочем, все релизы systemd распространяются в едином tar-архиве и находятся в одном git-репозитории с единым циклом выпуска.

    systemd сложный

    Нонсенс. Платформа systemd, на самом деле, гораздо проще традиционного Linux, потому что она объединяет системные объекты и их зависимости в юнитах с простым синтаксисом конфигурационных файлов. Также, у systemd есть вполне исчерпывающая документация о почти каждой детали systemd, в том числе и об API для разработчиков.

    Конечно, у systemd есть кривая обучения. Она есть у любого софта. Но systemd всё равно остаётся проще больших shell-скриптов, да и проще синтаксиса shell в целом.

    В целом, systemd, возможно, настолько прост, насколько системный менеджер может быть простым.

    systemd — продукт синдрома «not invented here»

    Это неправда. До того, как приступить к systemd, Поттеринг продвигал Upstart, впрочем, потом он пришёл к заключению, что дизайн Upstart неидеален: вместо того, чтобы самой решать проблему зависимостей, система оставляла это администратору. Но это лишь одна из причин.

    systemd — это не UNIX

    В этом есть некоторая правда: в исходных кодах systemd нет ни одной строки из UNIX. Но разработчики черпают вдохновение из UNIX, взгляните на те же десятки файлов, каждый из которых делает свою задачу. Кроме того, способ ведения проекта (т.е. развитие в одном git-репозитории) во многом похож на модель BSD (который настоящий UNIX, в отличии от Linux).

    Вообще, UNIX для каждого значит своё. Для Леннарта Поттеринга и других разработчиков это источник вдохновения, а для кого-то это религия, и, как и у других мировых религий, есть разные трактовки и понимания UNIX: под ним можно понимать стиль кода, набор команд и API, а кто-то считает, что UNIX — это набор логик и поведений.

    Конечно, сделать всех этих людей счастливыми просто невозможно.

    systemd раздут, это зоопарк разных фич и изменения ради изменений.

    systemd наверняка покрывает больше задач, чем должен был. Это давно не просто система инициализации, это система для построения операционной системы.

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

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

    Кстати, собирается systemd на удивление быстро: на моём i7-8550U сборка ядра v245 заняла 43 секунды.

    systemd нестабилен и забагован

    Вовсе нет. Мейнтейнеры, по мнению Леннарта, внимательно относятся к issues на GitHub, мониторят багтрекеры дистрибутивов Linux и, надо сказать, число багов довольно мало для такого ключевого компонента ОС.

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

    Использование systemd dbus-а вместо сокетов делает его интерфейс непрозрачным

    Это утверждение противоречит себе: dbus — это просто стандарт сериализации сообщений поверх обычных сокетов. Формат сообщений документирован и понятен, и к dbus есть множество библиотек для разных языков.

    В отличии от различных классических UNIX-демонов, у каждого из которых свои протоколы и форматы.

    Я перевёл лишь самую, на мой взгляд, интересную часть мифов. Остальные можете почитать здесь.

    В заключение


    Сегодня systemd — это больше, чем PID 1: это прослойка между kernel space и приложениями, которая обладает всем, что может понадобиться для работы дистрибутива Linux:

    • Широкий набор инструментов для решения большинства, если не любого, типа задач, связанных с управлением системой.
    • dbus API: почти каждый компонент systemd предоставляет интерфейсы в dbus, системе межпроцессного взаимодействия. Подробнее о dbus можно почитать тут и тут.
    • Модульность: пользователь дистрибутива или его разработчик может убрать, скажем, networkd и resolved, поставить на их место NetworkManager и dnsmasq, и всё будет работать.

    Но для меня лично systemd это даже больше, чем middleware: это новая эпоха в истории экосистемы Linux, в одном ряду с KVM, Wine, Kubernetes и другими технологиями.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 437

      +1

      А почему bash-completion так лагает при выводе подсказок по systemd? Это и на нескольких последних версиях Убунты, и на других дистрибутивах, судя по аналогичным вопросам на stackoverflow. Лечения так и не нашел.

        +3

        Ну, надо идти и смотреть, что там в completion навернуто. Не говоря о том, что это могут проблемы попросту конкретного дистрибутива.

        +10
        По правда говоря, это пост не о войнах systemd. Если хотите почитать ещё, но лень копаться в списках рассылки, то держите чей-то материал, который отчасти вдохновил меня на этот пост

        в этом "чьем-то материале" есть не только описания войн systemd, но и техническая критика. Мягко говоря, разгромная. Не обычная вода про "не юниксвей", а подробное описание архитектуры, в частности того ада которым там являются зависимости. Я думал, тут будет перевод именно этой, самой важной части статьи.

          +6
          Честно скажу: я не дочитал до конца. Вообще, я боялся, что статья получится чересчур большой, и на этот блог наткнулся где-то позавчера, ближе к концу написания материала, в общем, не осмелился приводить его полностью.
          Я думал, тут будет перевод именно этой, самой важной части статьи.

          Ну… Если вы захотите перевести эту часть поста и опубликовать самостоятельно, то я только за!
          0
          Ни одного серьезного аргумента зачем нужно было внедрять вместо понятных и легко читаемых rc-скрипотов в статье не увидел. Понятно, что чем шире используется система, тем больше падает средний уровень сисадминов, но тогда почему нужно останавливаться на пол-пути?
            +32

            Представьте, что вам нужен понятный и легко читаемый rc-script который:


            • запускает некий процесс, при этом:
              — гарантирует наличие сети к моменту его запуска
              — гарантирует наличие определенных mount-points к моменту запуска
            • перезапускает его если он вылетает при определенных кодах возврата
            • не даёт запустить больше чем один процесс (при повторных вызовах)
            • адекватно завершает процесс при shutdown но до того как отключатся сеть и некоторые другие процессы
            • всё вышеперечисленное должно работать одинаково (и надёжно) в debian/arch/centos

            Сколько строчек получилось? И насколько понятно-читаемых?

              –25
              Давайте я парирую вас по пунктам.
              запускает некий процесс, при этом:
              — гарантирует наличие сети к моменту его запуска
              — гарантирует наличие определенных mount-points к моменту запуска

              Такого не должно быть в правильном софте. Софт должен самостоятельно проверять необходимые ему зависимости, а не полагаться на третьи в общем виде недоваренные сервисы.

              перезапускает его если он вылетает при определенных кодах возврата

              Такие вещи нельзя отдавать на сторонний софт. А что будет, если успешное условие запуска так и не произойдёт? Вы получите постоянно перезапускающийся сервис.
              не даёт запустить больше чем один процесс (при повторных вызовах)

              Десятки лет это решалось наличием файлика daemon.pid в run директории.
              адекватно завершает процесс при shutdown но до того как отключатся сеть и некоторые другие процессы

              Опять же это должен делать сам софт, а не внешняя система запуска.
              всё вышеперечисленное должно работать одинаково (и надёжно) в debian/arch/centos

              Как раз с этим проблем не было.
                +21
                Такого не должно быть в правильном софте.

                Вместо того чтобы сделать инструмент который удовлетворяет большому количеству сценариев, говорить что ваши сценарии неправильные — это путь в никуда.

                У нас в городе адепты вашей логики, вместо удобной среды для всех, строят один неудобный пешеходный переход — в итоге люди бегают через дорогу там где удобно, создают аварии. Архитектор не виноват, это люди неправильные да?
                  +12
                  Такого не должно быть в правильном софте.

                  По такой логике правильного софта не существует.


                  Вы получите постоянно перезапускающийся сервис.

                  Поэтому systemd позволяет ограничить частоту и количество перезапусков.


                  Десятки лет это решалось наличием файлика daemon.pid в run директории.

                  Который можно случайно (не) удалить или случайно не создать. Или вообще устроить race condition. Это очень ненадёжно.


                  Опять же это должен делать сам софт, а не внешняя система запуска.

                  Зачем переусложнять софт тоннами проверок, если всё это может делать система инициализации? В чём смысл?

                    +6
                    Софт должен самостоятельно проверять необходимые ему зависимости, а не полагаться на третьи в общем виде недоваренные сервисы.

                    Во-первых, софт может и не знать, что у него есть какая-та там зависимость. Во-вторых, что делать когда этой зависимости нет? Если активно ждать зависимость — то это лишние паузы в процессе запуска системы плюс напрасная трата процессорного времени.


                    Такие вещи нельзя отдавать на сторонний софт. А что будет, если успешное условие запуска так и не произойдёт? Вы получите постоянно перезапускающийся сервис.

                    Постоянно перезапускающийся сервис вы получите если будете делать защиту от падений "на коленке". А systemd умеет останавливаться при повторяющейся ошибке.


                    Десятки лет это решалось наличием файлика daemon.pid в run директории.

                    Ага, и с гонками вокруг того файла.

                      +15
                      Софт должен самостоятельно проверять необходимые ему зависимости, а не полагаться на третьи в общем виде недоваренные сервисы.

                      То есть каждый софт который работает с сетью должен сам эту самую сеть настроить и запустить? А если ему нужен доступ к какому-то NFS то ещё и его подмонтировать?


                      Вы фактически предлагаете любое приложение превращать в отдельную OS.


                      А что будет, если успешное условие запуска так и не произойдёт? Вы получите постоянно перезапускающийся сервис.

                      Если условия для запуска не наступают — то логично что сервис не запустится вообще и "запускатель" будет ждать (с минимальным оверхедом) наступления условий (что делает systemd — и отлично делает). В случае с rc-script всё зависит от кривизны рук его писателя (обычно они кривые).


                      Вообще отслеживание зависимостей запуска должно быть сделано вне самого приложения — потому что приложение (сервис) может банально не иметь прав/знаний чтобы эти самые зависимости запустить/реализовать, всё что оно должно "мочь" — это сказать что ему нужно, а не как и где.


                      Десятки лет это решалось наличием файлика daemon.pid в run директории.

                      Угу… как уже упомянули выше — с этим связаны массы race conditions, не говоря уже о том что pid-file — это только поллинг, со всеми вытекающими.


                      Опять же это должен делать сам софт, а не внешняя система запуска.

                      Да без проблем — сервису для работы с (допустим) почтой доверим shutdown системы и корректное завершение работы БД, чтобы он успел всё что нужно сделать. Примерно так?

                        +7
                        Десятки лет это решалось наличием файлика daemon.pid в run директории.

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

                          +2
                          Короче говоря
                          > Это дает такие и такие удобства
                          > Удобства нинужны!
                          +7
                          init.d скрипты понятные? Один и тот же скрипт делающий одно и то же будет раз в 5 длинней, чем в systemd
                            0
                            Представьте, что вам нужен понятный и легко читаемый rc-script который:.....

                            Захожу по SSH в FreeBSD и вижу там скрипты которые делают все это и многое другое.
                            Причем написать свой не представляется большой трудностью даже без частых подглядываний в интернет только на основе того, что уже есть в базовой системе.
                            Как говорил Жванецкий: «Может нужно что-то в консерватории подправить?»
                              +1

                              Могу только съязвить, что линуксы между собой могут отличаться больше, чем Линукс (произвольный) отличается от бсд.
                              Ну, и, конечно, брать бсд как пример. Такое себе. Система хорошая, но больно узкоспециализированная по нынешним временам

                                +1
                                Захожу по SSH в FreeBSD и вижу там скрипты которые делают все это и многое другое.
                                А статью не напишите? Про то, как всё устроено. И как система поднимается, ждёт получения имени по DHCP, после чего решает откуда понтировать (через NFS) Web-сайтик и только после этого запустить Web-сервер. А FTP-сервер (монтирующийся с другого NFS-сервера) дожен, разумеется, работать даже если Web-сервер не поднялся.

                                Банальная такая задачка — будет интересно посмотреть как именно FreeBSD это всё разрулила. Кроме шуток.

                                Как говорил Жванецкий: «Может нужно что-то в консерватории подправить?»
                                Может быть. Статью реально жду. Потому что количество костылей, которые требовалось забить, чтобы что-то подобное сделать на бездисковых станциях под Linux у нас в школе… вызывало некоторую оторопь.

                                Бездисковые станции ушли в прошлое, но теперь те же самые задачи возникают на серверах. Если FreeBSD это успешно и надёжно решает скриптами — то будет интересно на это посмотреть.
                                  +1
                                  DHCP, NFS, вебсайтик через nfs и только потом запуск вебсервера — странно читать это все через запятую, особенно первые два пункта. А в этом точно есть необходимость (особенно на продакшене)? Больше похоже на сферического коня в вакууме.
                                    0
                                    Больше похоже на сферического коня в вакууме.

                                    больше похоже на машинку разработчика, который не осилил в докер или кубер :-D
                                    /шутка, в которой доля шутки/

                                    –2
                                    А статью не напишите? Про то, как всё устроено. И как система поднимается...

                                    На хабре много блогов, где коммерсы выкупили посты, а несчастные сотрудники потом занимаются переводом англоязычных статей и документации. Для них как раз идея подойдет. Остальным я бы посоветовал просто читать документацию, а не мои опусы.
                                    по DHCP, после чего решает откуда понтировать (через NFS) Web-сайтик и только после этого запустить Web-сервер. А FTP-сервер (монтирующийся с другого NFS-сервера) дожен, разумеется, работать даже если Web-сервер не поднялся.

                                    Здесь все просто:
                                    image
                                    Я думаю, все от того, что на той же самой машине не пытаются одновременно запустить Tensorflow, PyTorch, майнер и еще IP-телефония для жилого квартала куда-то пропала.
                                      –1
                                      Ну да, всё понял: вы его неправильно держите.

                                      Спасибо за рекламу systemd.
                                  +3
                                  Представьте, что вам нужен понятный и легко читаемый rc-script который:

                                  Давайте лучше не rc, с ними всё понятно, а лучше рассмотрим run-скрипт для Runit.


                                  • запускает некий процесс, при этом:
                                  — гарантирует наличие сети к моменту его запуска
                                  — гарантирует наличие определенных mount-points к моменту запуска

                                  Сеть и монтирования в Runit выполняются на 1-м (синхронном) этапе загрузки, до начала запуска (асинхронного) всех сервисов. Выглядит это примерно так:


                                  mount -at noproc,nofuse
                                  swapon -a
                                  
                                  ip link set lo up
                                  iptables-restore </etc/iptables
                                  
                                  ip link set eno1 up
                                  ip addr add 1.2.3.4/24 dev eno1
                                  ip route add default via 4.3.2.1 dev eno1

                                  • перезапускает его если он вылетает при определенных кодах возврата

                                  Runit это супервизор, который контролирует сервисы по SIGCHLD — иными словами сервис не должен демонизироваться, но зато нет никаких pid-файлов и race, сервис будет гарантированно автоматически перезапущен (1 раз в секунду если он непрерывно падает).
                                  Можно добавить (однострочный) finish-скрипт, который выключит сервис если он завершился с определённым кодом возврата (чтобы он перестал перезапускаться).


                                  • не даёт запустить больше чем один процесс (при повторных вызовах)

                                  Не даёт, разумеется. Попытка запустить уже запущенный сервис успешно завершается ничего не сделав.


                                  • адекватно завершает процесс при shutdown но до того как отключатся сеть и некоторые другие процессы

                                  Отключение сети и маунтов выполняется на третьем (тоже синхронном) этапе, после того как был инициирован shutdown/reboot и второй этап (запустивший все сервисы) был завершён (сервисы были остановлены).


                                  • всё вышеперечисленное должно работать одинаково (и надёжно) в debian/arch/centos

                                  Так и работает, достаточно поставить и запустить runit.


                                  Сколько строчек получилось? И насколько понятно-читаемых?

                                  Ну, как сказать. Приведу несколько примеров. Начнём с простого: sshd.


                                  $ cat /etc/sv/ssh/run
                                  #!/bin/sh
                                  exec &>/var/log/all/.log
                                  exec /usr/sbin/sshd -D

                                  Но это скучно. Давайте что-то по-сложнее, dbus:


                                  $ cat /etc/sv/dbus/run
                                  #!/bin/sh
                                  exec 2>&1
                                  mkdir -p /var/run/dbus
                                  rm /var/run/dbus.pid
                                  dbus-uuidgen --ensure=/etc/machine-id
                                  exec dbus-daemon --nofork --system

                                  Ну или давайте что-то с зависимостями от других сервисов, напр. postfix:


                                  $ cat /etc/sv/postfix/run
                                  #!/bin/bash
                                  exec 2>&1
                                  sv start /etc/service/postsrs &>/dev/null || exit
                                  sv start /etc/service/postgrey &>/dev/null || exit
                                  sv start /etc/service/opendkim &>/dev/null || exit
                                  sv start /etc/service/opendmarc &>/dev/null || exit
                                  exec postfix start-fg

                                  Ну и на закуску X-ы:


                                  $ cat /etc/sv/x/run
                                  #!/bin/bash
                                  exec &>/var/log/all/.log
                                  sv start /etc/service/*tty* &>/dev/null || exit
                                  sv start /etc/service/dbus &>/dev/null || exit
                                  sv start /etc/service/elogin &>/dev/null || exit
                                  . /etc/profile
                                  exec slim -nodaemon

                                  Как Вам количество строчек и их читаемость?


                                  P.S. Забавный факт: официально в runit вообще нет поддержки зависимостей между сервисами, считается, что если сервис при запуске не нашёл чего-то необходимого, то он просто упадёт и будет перезапущен 1-2 раза (а в тому моменту сервисы, от которых зависит этот уже будут готовы к работе). Так что вышеупомянутая "реализация" зависимостей между сервисами — это по большей части моё баловство, не всегда обязательное. Полноценная поддержка зависимостей есть в S6, так что кому не хватает функционала Runit просто берёт S6, там намного больше фич.

                                    +2

                                    Выглядит круто, но есть куча вопросов


                                    1. что с параллельностью запусков сервисов? То что здесь я вижу — скорее последовательный запуск. То что я увидел у Вас — это не зависимости, а чертизнаетчто.
                                    2. в systemd основная фишечка — это расширяемость и переопределение. Вот, скажем, постфикс — он притаскивает свой системный юнит. Меня он не устраивает. Что я делаю? Я закидываю переписанный юнит на /etc/systemd/system или дроп-ины туда и я уверен, что при обновлении пакета постфикса мои изменения не будут перезаписаны. Это на самом деле очень важно.
                                    3. Что делать если нужны дополнительные возможности — вроде засовывания целых поддеревьев процессов в це-группы, лимитирование по памяти, процессору и прочие продвинутые штуки?

                                    И многое другое. Я так понимаю, что в рамках примера "runit — простой до безобразия" Вам это не удалось сделать. В ключе же, что "соберу свой дистрибутив с нуля" — да, это возможно альтернативный, возможный подход. Но точно не в production, чтобы все было унифицированно, понятно, исправляемо любым квалифицированным инженером (=поддерживаемо) и относительно дешево.

                                      +2

                                      Сервисы запускаются параллельно всегда. Где Вы там увидели последовательный запуск — я без понятия. Ещё раз, у runit 3 стадии работы:


                                      1. На первой выполняется один скрипт, который инициализирует систему синхронно (mount, udev, fsck, sysctl, net — вот это вот всё). Тут нет особо долгих или блокирующих операций, поэтому выполняется он за 3-5 секунд, что не имеет никакого значения, учитывая как часто перегружаются машины.
                                      2. На второй одновременно запускаются все сервисы, без учёта каких-либо зависимостей. Если каким-то сервисам чего-то нехватило — они падают и автоматически перезапускаются через 1 секунду.
                                      3. Третья запускается в момент shutdown/reboot, это тоже один синхронный скрипт как на 1-й стадии, он сначала останавливает все сервисы, а потом выполняет необходимые операции перед отключением (hwclock, alsactl, random, net, umount). Он так же отрабатывает за пару секунд.

                                      В целом, такое разделение операций на синхронные (1,3) и асинхронные (2) позволило сильно упростить всё — и реализацию самого runit, и понимание мной как админом что и как происходит при загрузке и отключении системы.


                                      Вот, скажем, постфикс — он притаскивает свой системный юнит. Меня он не устраивает.

                                      Ну, в Runit с этим всё хорошо. В смысле, postfix ничего про runit не знает, и своих юнитов не притаскивает. Вышеупомянутый мной run-файл пишется ручками, под нужды текущей системы. Напр. у моего папы на компе postfix нужен чисто для отправки почты (можно было какой-нить ssmtp поставить, наверное), поэтому у него run-файл postfix выглядит вот так:


                                      #!/bin/sh
                                      exec postfix start-fg 2>&1

                                      И да, представляете, написать такое руками займёт примерно столько же времени, сколько установить этот файл каким-нибудь apt install postfix-runit.


                                      По сути, я именно это и пытаюсь Вам всё это время объяснить: загрузка системы и запуск сервисов может (и должен) быть намного-намного проще, чем это сделано в sysvinit и systemd.


                                      засовывания целых поддеревьев процессов в це-группы, лимитирование по памяти, процессору и прочие продвинутые штуки?

                                      Ну, тут такое дело. Если Вам реально необходимы все те продвинутые фишки systemd — значит надо использовать systemd и платить запрошенную им цену (сложность), потому что в этой ситуации данная цена является приемлемой.


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


                                      P.S. Впрочем, если речь не о cgroups, а о более традиционных ограничениях (chroot, uid/gid, env, ulimit, …) то для этого существует куча мелких утилит (идущих в комплекте и с daemontools, и с runit, и с s6 — напр. вот chpst из runit), которые обычно вызываются из run-файла цепочкой. Например, запуск внутри chroot под юзером nobody (плюс обновление бинарников и so-библиотек внутри chroot-каталога):


                                      $ cat /etc/sv/3proxy/run
                                      #!/bin/sh
                                      exec 2>&1
                                      
                                      # update binaries and libraries
                                      for f in $(find root/ -type f -perm /001 | sed s,^root,,); do
                                          cp "$f" "root$f"
                                      done
                                      
                                      exec chpst -/ root/ -u nobody /usr/bin/3proxy /etc/3proxy.cfg
                                        –1
                                        выполняется он за 3-5 секунд

                                        У меня через 5 секунд уже графическая форма логина отображается, при том что ещё даже не все USB-устройства проинициализированы на тот момент.


                                        они падают и автоматически перезапускаются через 1 секунду.

                                        Бессмысленное засирание логов тоннами ошибок, systemd в этом плане явно лучше.

                                          +3

                                          Ну, насколько я понимаю, львиную часть этих 3-5 секунд съедает как раз блокирующая инициализация udev (т.е. по сути код Вашего любимчика Поттеринга). Впрочем, это не важно. Если кому-то экономия 2-3 секунд на перезагрузке компа компенсирует сложность systemd — значит он понимает, зачем ему нужен systemd и всё в порядке. Я лично комп перегружаю примерно раз в месяц для обновления ядра, и мне эта экономия сложность systemd точно не компенсирует. (Кстати, на соседнем компе Debian 10 с systemd, и я что-то не замечал, чтобы он грузился быстрее моего, а точнее он грузится заметно медленнее, хотя в автозапуске у него меньше всего и нет браузера, в отличие от моего компа.)


                                          Бессмысленное засирание логов тоннами ошибок

                                          Ну вот откуда вы все это берёте… Между сервисами не так много зависимостей (особенно если не считать "сервисами" вещи вроде fsck/mount/net — которые в Runit делаются до запуска всех сервисов), они не так часто умудряются запуститься настолько неудачно, чтобы это сломало зависимости и кто-то из них упал, плюс вышеупомянутый мной пример проверки зависимостей прямо в run-файле позволяет просто не запускать сервис (и не писать ничего в лог) пока зависимости не готовы. В результате в логах если и бывают ошибки на эту тему, то буквально одна на все сервисы, и то не при каждом перезапуске. (Иными словами systemd опять решил несуществующую проблему.)

                                            +4
                                            Ну вот откуда вы все это берёте…

                                            Из практики. Какой-нибудь danted зависит от сетевых интерфейсов, какой-нибудь Django-сайт зависит от запущенного MySQL и насыпет ошибок в лог при его отсутствии, и так далее


                                            вышеупомянутый мной пример проверки зависимостей прямо в run-файле

                                            И это всё вместо того, чтобы написать одну строчку?


                                            After=opendkim.service opendmarc.service mysqld.service


                                            Ваш пример является отличной антирекламой runit. Я предпочту написать одну строчку декларативного конфига, чем десяток строчек мутных скриптов с кучей ручных проверок.

                                              0

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

                                                +1

                                                Ну, как сказать "забить". Если юзеры честно получали эти 500-е — я бы хотел видеть их в логах, это поможет саппорту разбирать жалобы юзеров.


                                                Но в общем случае всё, что я тут пишу про runit — это про системные сервисы. Я не принимаю во внимание запуск самописных и прочих "enterprise" сервисов на java и нужных им БД, потому что всё это обычно запускается в докере/кубе, и проблемы эти разруливаются (или нет) средствами докера/куба. Нет, серьёзно, когда-то действительно выкатывать их ансиблом в systemd было разумным, но в 2020-то зачем так делать?

                                                  +4
                                                  в 2020-то зачем так делать?

                                                  Затем, что почему бы и нет? Выкатываю ансиблом в systemd все свои серверы и радуюсь жизни. Зачем тратить драгоценные ресурсы вдсок на жирнющий докер и возиться с его настройкой и написанием обмазанных костылями докерфайлов — не знаю. (У ансибла, впрочем, есть свои недостатки, но systemd тут уже ни при чём)

                                                    0

                                                    Вопрос "зачем нужен докер для собственных сервисов" несколько выходит за рамки обсуждения systemd. Но в ответе на него обычно звучат слова "тесты/CI, контроль внешнего окружения, простота запуска проекта на машине разработчиков, лёгкая переносимость между серверами, …".


                                                    Насчёт жирнющий и настроек — первый раз слышу такие претензии в отношении докера, особенно в контексте enterprise-java-сервисов, на фоне которых демон докера теряется по определению. А настройка обычно сводится к перенаправлению логов в более подходящее место и запуску docker swarm init|join.

                                                      +3
                                                      особенно в контексте enterprise-java-сервисов

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


                                                      А слова "тесты/CI, контроль внешнего окружения, простота запуска проекта на машине разработчиков, лёгкая переносимость между серверами, …" легко реализуются и без докера, если руки из правильного места растут.


                                                        +3
                                                        лёгкая переносимость между серверами

                                                        да-да-да, это пока не выясняется одно из нескольких:


                                                        1. версия докера не та (были проблемы, если образы собранные последним докером запускать на более старом)
                                                        2. нужны какие-то специфичные sysctl (напр., для запуска эластика)
                                                        3. пока архитектура процессора та же — если скомпилировали код с оптимизациями под xeon, то он запросто может не запуститься на amd — тупо illegal instruction и все. Это как бы не собственно проблема докера, а ложь об обещаниях переносимости (она сама внезапно не появляется, но современному поколению это неизвестно)
                                                        4. пока не нужно засунуть systemd внутрь докера — там целая эпопея с приключениями
                                                        5. пока не нужен специфичный драйвер оборудования
                                                        6. пока не нужен privileged режим

                                                          где-то тут еще могут стрельнуть особенности работы сети с докером (привет, телефония и прочие штуки) или особенности работы с диском

                                                        и масса другого. Т.е. отрицать то, что докер отрыл новую страницу в истории и популяризировал контейнеризацию нельзя. Но натянуть на него все возможные юзкейсы… попросту нормально не получается. Да и не нужно.


                                                        docker swarm init|join.

                                                        swarm мертв, закопайте его труп и забудьте его уже.

                                                          0
                                                          напр., для запуска эластика

                                                          Это какие? Разве что число дескрипторов, но такие вещи делаются на самом хосте.
                                                            +1
                                                            Разве что число дескрипторов, но такие вещи делаются на самом хосте.

                                                            так об этом и речь! Переносимости нет (контейнер стартанет и упадет) — пока не настроишь хост. В общем-то возможно пример не особо честный, но просто надо иметь в виду, что абстракции текут. И это надо уметь учитывать.

                                                              0

                                                              Не всегда это возможно.

                                                                0
                                                                Например?
                                                                  0

                                                                  managed сервер или кластер. Нам только докер/кубер ендпоинты открыты.

                                                                    0
                                                                    Если говорить об эластике, чтобы он дефолтные лимиты превысил, это надо крутить довольно большой инстанс, который неплохо распилить на более мелкие, ибо эластик так не любит. А там и лимиты трогать не придется.
                                                                      0

                                                                      Дефолтный образ эластика в докере на дефолтных настройках убунты вроде тупо не поднимается.

                                                                        0
                                                                        Ну не знаю. У меня эластик docker.elastic.co/elasticsearch/elasticsearch:7.6.1 на обычной убунте. Индекс на 100гб, 5 шардов, все норм.
                                                                          0

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

                                                              +1
                                                              swarm мертв, закопайте его труп и забудьте его уже.

                                                              Standalone swarm — да. Встроенный в докер — живее всех живых, и отлично заменяет намного более сложный куб в большинстве мелких/средних проектов.

                                                            0
                                                            жирнющий докер

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

                                                              все так, но иногда оверхед от докера вылезает :-/

                                                                0

                                                                100-150МБ оперативы на демон докера — раз.


                                                                Гигабайт-другой на скачивание образов ubuntu/debian/alpine, причём в разных контейнерах разные их версии — два.


                                                                Оверхед на сеть, на что жалуются примерно все пользователи докера — три.


                                                                И всё это пихать на вдску с 1ГБ оперативы и 10ГБ HDD? Спасибо, не надо.


                                                                Плюс полно других рантаймов, которые легче

                                                                В любом случае мне и без докера хорошо.

                                                                  0
                                                                  Гигабайт-другой на скачивание образов ubuntu/debian/alpine, причём в разных контейнерах разные их версии — два.

                                                                  Алпайн весит 3МБ, убунта 30МБ. О чем вы?

                                                                  Оверхед на сеть, на что жалуются примерно все пользователи докера — три.

                                                                  На подобной вдске? Смешно. А что до жалоб — я не встречал подобных жалоб за года работы с докером (что скорее означает, что проблемы либо нет, либо она вызвана не докером, либо встречается в очень специфичных кейсах), а исследование IBM показывает ничтожную разницу, которую чтобы разглядеть в продакшене я не знаю что надо делать. А уж когда работаешь на таком уровне, то как правило есть железо, чтобы было пофиг на этот оверхед.

                                                                  Что до оперативки, если 100мб это настолько дорого, то это уж совсем какой-то странный кейс. Но ладно, кому-то может надо экономить даже настолько.
                                                                    +1
                                                                    Алпайн весит 3МБ, убунта 30МБ.

                                                                    В реальном использовании на многочисленных разных образах набегает несколько гигабайт.


                                                                    это уж совсем какой-то странный кейс.

                                                                    Рад за вас, если у вас завались денег и вы можете скупать дедики целыми стойками, не задумываясь об оперативке. К сожалению, я не из таких. Запустится с десяток служб по 100МБ — и всё, оперативка кончилась, привет swap и OOM Killer.

                                                                      –1
                                                                      В реальном использовании на многочисленных разных образах набегает несколько гигабайт.

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

                                                                      Запустится с десяток служб по 100МБ

                                                                      Откуда десяток уже взялся, когда докер один?
                                                                        0
                                                                        Откуда десяток уже взялся, когда докер один?

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

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

                                                                          Вы же понимаете, что на сервере докер будет далеко не единственным процессом?

                                                                            0
                                                                            Вы просто странно перешли с докера на 100мб до десятка сервисов по 100мб, будто тут докер виноват в этих сервисах. А так, ну да, вместо десяти сервисов запустить получится 9. У меня правда подозрение, что в настолько ограниченной среде, OOMKiller придет запросто и без всяких докеров. Как у вас там вообще все работает? Своп есть хотя бы? Но так да, если счет на мегабайты, докер тут лишнее звено. Я действительно привык работать с серверами, где контейнеров сотни крутится, поэтому один докер демон там это капля в море.
                                                                              0
                                                                              будто тут докер виноват в этих сервисах

                                                                              Ну так докер один из сервисов. Если у меня есть возможность не занимать лишние 100МБ — зачем мне их занимать? Я их лучше мускулю выдам, чтобы он чуточку быстрее запросы выполнял.


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

                                                                0

                                                                Вот как раз у докера таких средств нет, у докер-композ почти нет, а у кубера опять нет.

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

                                                                    Да! :) Но делать-то нечего, запускается всё это всё-равно в докере… так что наличие этих средств у systemd ничем не поможет.


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

                                                                      +3
                                                                      Падение базы это вообще не штатная ситуация. Это катастрофа, поэтому 500 ошибки это нормально. 500 ошибки на старте сервиса, потому что он стартанул раньше базы, это не нормально. И решать это можно двумя способами — указать зависимости через init систему или делать это в коде. Тут дело вкуса.
                                                                        0

                                                                        База, обычно, часть сервиса. И вот тут какой-нибудь сервис дискавери видит, что сервис есть, 80-й порт слушает, а по факту у него один ответ — 500 с каким-нибудь mysql has gone

                                                                      +1
                                                                      «Так делать не надо» это не аргумент. Люди делают так и для этого полно причин, иногда чисто технических, когда вне докера работает лучше и быстрее. У вас за скромные несколько постов здесь уже набралась пачка «зачем так делать». Все это лишь показывает, что ваш runit не решает реальные задачи или требует для этого помойку из скриптов, от которой все как раз и хотели уйти.
                                                                        0
                                                                        У вас за скромные несколько постов здесь уже набралась пачка «зачем так делать».
                                                                        Угу. И при этом ещё усиленное педалирование количества Issues.

                                                                        Конечно если все баги закрывать с WONTFIX или NOTERROR — то ни одного бага в таком софте не будет.

                                                                        Но захотите ли вы им пользоваться?

                                                                        Антиреклама Runit получилась знатная, надо сказать…
                                                                          0
                                                                          Конечно если все баги закрывать с WONTFIX или NOTERROR — то ни одного бага в таком софте не будет.

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

                                                                +8
                                                                Если каким-то сервисам чего-то нехватило — они падают и автоматически перезапускаются через 1 секунду

                                                                Потрясающий ход, конечно.
                                                                  –5

                                                                  Таки да! Простой, очевидный, и надёжный. Из потенциальных недостатков разве что "засирание логов", но я про это ответил выше — на практике этой проблемы нет.

                                                                    0
                                                                    А так же бесполезная трата ресурсов на эти перезапуски.
                                                                      –1

                                                                      Да, трата. Но во-первых это количество ресурсов пренебрежимо мало, и во-вторых вовсе не бесполезная: её польза в возможности использовать значительно более простой и надёжный инструмент — runit.

                                                                        +9
                                                                        Это ваше мнение, что они пренебрежимо малы? А если сервис тяжелый и требует много ресурсов на запуск только для того, чтобы упасть, потому что сеть видите ли не поднялась еще? Односекундная задержка это типичное решение скрипткидди, которые не умеют в координацию процессов. Если сервисов несколько, то рано или поздно будет ситуация, когда все сервисы одновременно падают и перезапускаются, тратят кучу ресурсов на это. Мое мнение, подобных подходам нет места в современных ОС. В embedded и прочих мелких устройствах — может быть. Там фиксированная конфигурация, нет смысла городить огород. Там и обычные rc скрипты устраивают.
                                                                          +3

                                                                          Пренебрежимо мало, пока вас в энтерпрайзе не просят запустить какую-нибудь джава или вебсферу.

                                                                    +2
                                                                    Если каким-то сервисам чего-то нехватило — они падают и автоматически перезапускаются через 1 секунду.

                                                                    Фактически, это busy wait. Ничего хорошего в нём не вижу.
                                                                    И не факт, что они потом перезапустятся.


                                                                    Вот ситуация в моём случае: имеется сервер OpenVPN, серверу требуется сетевой мост. Так вот иногда случается, что при старте системе он запускается слишком быстро — раньше, чем поднимется мост, из-за чего сервис не упадёт, а будет просто работать некорректно. То есть придётся сначала зайти по ssh и перезапустить сервис.

                                                                      –1

                                                                      В runit сеть настраивается до запуска всех сервисов.


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

                                                                        +2

                                                                        У вас очень opinionated view. Сеть и ее настройки — это не монолит. Как пример, ВПН запускается только тогда, когда есть активный интерфейс. Или на фрилансим регулярно вижу — напишите скрипт, который ВПН внутри впна, который внутри третьего впна. На системди не без боли, но сделаешь. На runit?

                                                                          –3

                                                                          Честно говоря, мне такое делать пока не приходилось. Насколько я понимаю, при использовании wireguard это всё заработает автоматически, достаточно просто запустить все три. При использовании OpenVPN, вероятно, придётся добавить в run-файл VPN2 зависимость от наличия нужного интерфейса VPN1 (предположим, VPN1 поднимает tun1, VPN2 поднимает tun2, …):


                                                                          ### в начале /etc/sv/openvpn2/run:
                                                                          ip link show tun1 &>/dev/null || exit

                                                                          но вот что случится если/когда этот интерфейс временно отвалится — вопрос любопытный. Если само не заработает, то придётся в finish-скрипт первого openvpn добавить перезапуск зависящего от него второго:


                                                                          ### в /etc/sv/openvpn1/finish:
                                                                          sv t openvpn2
                                                                            +1
                                                                            в начале /etc/sv/openvpn2/run:

                                                                            ip link show tun1 &>/dev/null || exit

                                                                            Разрешите потроллить? А чего iproutes, а не старый добрый ifconfig? Или все-таки достижения последних лет не так плохи (включая сустемди)?

                                                                              0

                                                                              Достижения последних лет бывают полезные и не очень. К счастью, iproute2 можно взять не беря "в нагрузку" systemd.

                                                                          0

                                                                          Ага, а теперь добавлю пикантную подробность: изначально всё настраивалось в Ubuntu 14 (без systemd).

                                                                            +6
                                                                            В runit сеть настраивается до запуска всех сервисов.
                                                                            Гениальность просто зашкаливает. Напоминает историю с мой прошлой работе, когда экскаватор перерубил оптику и ни один комп нельзя было перезагрузить пока сеть не восстановится, так как они все банально висли на этапе «достучаться к NFS-серверу из соседнего офиса».

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

                                                                            Иными словами, описанная Вами проблема сначала была искусственно создана (кто-то решил, что абсолютно всё-всё надо сделать «сервисами» и запускать асинхронно), а потом потребовалось героически и с кучей лишних сложностей её решать.
                                                                            Отчасти согласен. С тем только лишь замечанием, что вот как раз «поднятие сети» и «монтирование файловых систем» — точно нужно делать асинхронно.
                                                                              –1

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


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

                                                                      +1
                                                                      Сеть и монтирования в Runit выполняются на 1-м (синхронном) этапе загрузки
                                                                      Отлично. У нас упал NFS-сервер отвечающий за /home/build (без него система вполне работоспособна, только не работает распределённая сборка… она не всем и не всегда нужна).

                                                                      Как Runit разрулит эту проблему, когда я смогу войти в свою любимый GNOME (KDE, XFCE, нужное подчеркнуть) и, главное, что будет с теми сервисами, которым нужен-таки /home/build?

                                                                      Полноценная поддержка зависимостей есть в S6, так что кому не хватает функционала Runit просто берёт S6, там намного больше фич.
                                                                      Как именно происходит переход?

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

                                                                        Не знаю, мне пока хватало возможностей runit. Но если/когда понадобится что-то, чего runit не умеет — буду переходить на s6.


                                                                        Немного напрягает то, что runit вообще не развивается много лет — автор считает его "законченным". В каком-то смысле так и есть, он делает всё необходимое (из поставленных перед ним изначально задач) и делает это хорошо — багов нет, всё работает. Но опыт показывает, что в long term эта стратегия с софтом, к сожалению, не работает — окружающий мир меняется, и достаточно сильно, поэтому софт, который этот факт игнорирует и не развивается вместе с миром — умирает. Пока что изменения мира никаких проблем с runit не создали, но первый "звоночек" уже прозвучал — поддержка cgroups выглядит интересной, хоть и не особо нужной (для системных сервисов) фичей… только вот уже появился сервис elogind (вытащенный logind из systemd) которому для работы нужны предоставленные менеджером сервисов cgroups (к счастью, в нём есть возможность реализовать этот функционал в нём самом, а не ждать его от менеджера сервисов, так что пока обошлось). А вот S6 активно развивается, так что "путь отхода" с runit доступен, если он вообще понадобится, конечно.

                                                                          0
                                                                          поддержка cgroups выглядит интересной, хоть и не особо нужной (для системных сервисов) фичей…

                                                                          Вы думаете, что ненужной, а вот когда у нас на корп сервер, где пасется 100+ не могли войти, из-за того, что пользовательские сессии были кривые… Ну, Вы поняли ) Там бы цегруппы пригодились

                                                                    +3

                                                                    А почему однотипный код в программах выносят в функции, а не дублируют его?

                                                                      +13

                                                                      Понятных? Не соглашусь. Мне понадобилось написать самому первые такие скрипты незадолго до того, как в arch пришел systemd. Так что я точно могу сказать, что без опыта разобраться в systemd'шных сервисах оказалось проще и быстрее (а я смотрел, как решить мою задачу на убунте, центоси и когда я отчаялся — полез гуглить, узнал про systemd, попробовал его), и я просто поставил на тот сервер arch и решил задачу. И до сих пор рад, systemd + ansible это прям удобно.

                                                                        +8

                                                                        Когда-то я пакетировал программы для нескольких дистрибутивов (и по работе, и в качестве хобби). Писать и модифицировать rc-скрипты для некоторых тяжёлых программ было очень сложно.


                                                                        Слишком много времени прошло, чтобы привести конкретные примеры. Но точно помню, что проблем было очень много, особенно, с сервисами, написанными на Java.


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


                                                                        Уже давно не занимаюсь такими вещами, поэтому, возможно, мой нынешний опыт не очень релевантен, но я счастлив теперь, когда мне нужно запускать на сервере какой-нибудь свой или кастомный софт, и просто пишу несколько строчек в systemd unit файл, и оно идеально работает с первого раза. С SysVinit однозначно было в несколько раз больше возни.

                                                                          +7

                                                                          Потому что systemd позволяет сделать запуск маленького читаемого скриптика И ЕЩЁ КУЧУ ВСЕГО, при этом оставаясь читаемым. Если кроме скриптика ничего больше не нужно, ничего не мешает сделать systemd-юнит, который будет только запускать этот скриптик и больше ничего.


                                                                          Для меня знакомство с init и systemd случилось одновременно ("перепиши", говорит, "вот эти скриптики, ну ты разберёшься"), и честно скажу, systemd гораздо, гораздо понятнее и, эм, документированнее.

                                                                            +1
                                                                            Не говоря о том, что уже были готовые и рабочие init'ы (runit, OpenRC, InitNG например).
                                                                            +9

                                                                            Да, поддержу, что как система инициализации systemd на порядки превосходит sysvinit.
                                                                            Помню, было прямо откровение, когда в первый раз здоровенная и не очень надежная баш портянка инициализации превратилась в надежный, простой и понятный systemd юнит.
                                                                            А вот с journald не сложилось. Бинарный формат — печаль, т.к. не пригоден для легкого просмотра.

                                                                              –2

                                                                              journald прекрасен, т.к. Вам логи глазами все равно напрямую смотреть не нужно — почти наверняка Вы логи фильтруете (стандартные текстовые) grep'ом или чем угодно, чтобы выбрать нужное. Ну, так пользуйтесь journalctl — делов-то. Это раз. Два — логи на машине это в целом ненадежная вещь — их можно сливать в некое централизованная хранилище, а там уже гуй, поиск, дашборды и все такое. Третья история, что по сути написав приложение по 12 factor app, что сейчас и не только модно, но и является необходимостью, просто пакетируете его для установки на сервер с systemd unit'ом и вуаля! Все логи собираются, красота.

                                                                                +3

                                                                                По-моему journald это один из тех компонентов который тянет systemd вниз.
                                                                                Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач, на самом деле нет:


                                                                                time sudo journalctl -n 10 --no-pager
                                                                                real    0m8,817s
                                                                                user    0m0,020s
                                                                                sys     0m0,059s

                                                                                в то время как с того же диска и точно так же с "холодным" дисковым кэшем:


                                                                                time tail -n 10 /var/log/pacman.log
                                                                                real    0m0,022s
                                                                                user    0m0,004s
                                                                                sys     0m0,000s

                                                                                Все бы ничего, но systemctl status использует journald и поэтому тоже дико тормозит: https://github.com/systemd/systemd/issues/2460


                                                                                Или захочется использовать центрилизованный сбор логов и можно поиметь кучу проблем: https://habr.com/ru/company/southbridge/blog/317182/, некоторые не решаются годами: https://github.com/systemd/systemd/issues/1387

                                                                                  0

                                                                                  Спасибо за комментарий по существу.


                                                                                  https://habr.com/ru/company/southbridge/blog/317182/

                                                                                  Знаю такую историю. И я бы тоже не стал журналом передавать журнал на удаленную машину. У меня есть достаточные опасения (как и у Вас), что это не будет нормально работать. Но с внешним решением — будь то rsyslog или fluent-bit — все прекрасно передается по удаленному протоколу.
                                                                                  Еще добавлю, что была прекрасная вводная статья от Селектел по вопросу journald.

                                                                                    0
                                                                                    Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач, на самом деле нет:

                                                                                    Разрешите вопрос? А что мешает Вам в Вашей личной конфигурации подмонтировать раздел под логи с HDD-накопителя? Или вы думаете, что дефолты в конкретном дистрибутиве говно? А зачастую это так. Но тогда причем тут системди?

                                                                                      –1
                                                                                      Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач
                                                                                      в 2020 году стало сложновато найти десктоп с hdd, тенденция к «hdd где-то там далеко в облаках/на серверах», а в рабочих станциях и домашних компах одни только ssd. Гибриды ssd + hdd в одной машине — издержки переходного периода, который потихоньку заканчивается.
                                                                                      Ну и — ничто не мешает же смонтировать hdd в /var/log.
                                                                                        –6
                                                                                        разумно ведь в desktop системе все логи писать на HDD

                                                                                        У вас в 2020 году HDD на десктопе? Даже без bcache? А что-за диск, кстати, не какой-нибудь пыльный Seagate 15-летней давности или люто тормозной WD Green случайно?


                                                                                        но systemctl status использует journald и поэтому тоже дико тормозит

                                                                                        Это никому не нужно. Большинство на SSD живут. Поэтому Поттеринг разумно выжидает, пока все оставшиеся некроманты не перейдут на SSD.


                                                                                        Или захочется использовать центрилизованный сбор логов

                                                                                        Ну опять же — если очень надо, то делайте PR на гитхаб. Очевидно, что этот функционал не особо востребован, поэтому тикет висит несколько лет, а решить его некому.


                                                                                        Для сбора логов есть другие, более подходящие средства.

                                                                                          +5
                                                                                          У вас в 2020 году HDD на десктопе?

                                                                                          Это никому не нужно. Большинство на SSD живут.
                                                                                          А что тут такого сверхъестественного? В тех же самых ноутбуках есть выбор, условно либо HDD на 1 Тб, либо SSD на 256 Гб за сравнимые цены.
                                                                                            –4

                                                                                            У меня 9-летней давности ноут с 500Гб SSD. Что я делаю не так?


                                                                                            Цены? Ну вроде как в IT индустрии на зарплаты люди не жалуются?


                                                                                            (сразу добавлю, что ноут — это ThinkPad x220 и он старый не потому, что денег нету на новый :)

                                                                                              –1
                                                                                              Цены? Ну вроде как в IT индустрии на зарплаты люди не жалуются?
                                                                                              Разумеется все остальные, не айтишники, а так же те, кто только начал работу и всё ещё не получает условные 1000 в месяц тоже могут купить объёмный ssd. И именно по этой причине для windows 10 рекомендуют ssd.

                                                                                              Лично я для себя преимуществ ssd не вижу. Ускорение загрузки раз в месяц не стоит тех денег.
                                                                                                0

                                                                                                Есть хорошие по железу/цене ноутбуки с комбинациями типа SSD 512Gb + HDD 2Tb


                                                                                                Ну и не только айтишники ноутбуками пользуются.

                                                                                                  +3

                                                                                                  Ну, вообще я долго пользовался линуксами на ноутбуках — где-то с поколения thinkpad t4x. И в целом складывается впечатление, что это костыли и велосипеды. Чего только стоит, что постоянно что-то приходится вручную доконфигурировать. Есть постоянно маленькие досаждающие баги (из серии "блютуз не включается"). Танцы с установкой — uefi/legacy/secureboot. Но в целом обычно работоспособная конфигурация получается. И все относительно ровно. Но вот время работы от АКБ прям расстраивает. По сравнению с ним же под виндой. Для меня это особой проблемой не было — розетка обычно есть. Но кто-то другой может расстроиться.

                                                                                                    +1

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

                                                                                                      +1
                                                                                                      На моем прошлом ноуте была ровно диаметрально противоположная ситуация. 5 часов автономки под Linux и 1.5-2 (если очень повезет) под его штатной Win7.
                                                                                                        0

                                                                                                        А как такое возможно? Пробовали разобраться?

                                                                                                          0
                                                                                                          Мне было не особо интересно. Меня вполне устраивало время работы в Linux. Примечательно, что при запуске Win7 система охлаждения выходила сразу на большие обороты и почти никогда с них не уходила (в taskman при этом нагрузка по нулям отображалась).
                                                                                                        0
                                                                                                        У меня вообще постоянно были какие-то «приколы» с acpi под thinkpad. Thinkpad x280 с OpenSUSE на борту сам просыпался с закрытой крышкой, включал кулеры на максимум гудел 5 мин и потом засыпал, потом опять через какое-то время просыпался. И если это все происходило в сумке или рюкзаке — то он там жарился как в печке. Если успевал замечать что что-то не так, открывал сумку чтобы он «подышал свежим воздухом». В конечном итоге такой постоянный перегрев и привел к поломке — отвалился проц.

                                                                                                        Мое мнение после 10 лет эксплуатации линукса на ноутах(thinkpad x серии и vaio) — для мобильного рабочего места линукс не подходит, будет какая-то фигня вылазить постоянно, вот для сервера или десктопа очень даже неплохо.

                                                                                                        Поэтому перешел на мак потому что в нем в отличии от thinkpad, нормальное охлаждение(кулеры+алюминиевый корпус), нормальный корпус(пластик скрепит, царапается, затирается), нормальная ось(режим сна работает). При этом и мак и thinkpad x серии в одну цену. И это уже не тот старый добрый thinkpad от ibm в котором корпус был титановом-магниевый.
                                                                                                          –1

                                                                                                          Все именно так, поэтому сижу на macbook pro 13
                                                                                                          В теории можно возродить историю с thinkpad на новом уровне, но очевидно, что это будет гик продукт. И поэтому стоимость будет ого-го, а проблем надо решить массу. С другой стороны, у этих же ребят что-то получилось https://system76.com/laptops/lemur ?

                                                                                                            +2
                                                                                                            Я на ситуацию смотрю под другим углом. С 2000 года поработал под кучей операционок, и винда была, и линуксы разные, и фряха с опенбсд, и маки.

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

                                                                                                            Поклонником thinkpad являлся до последнего, но терпение вышло, да и сидеть на старом «трушном» железе уже проблематично, хотя и таких знаю, кто до сих пор покупает старые ibm thinkpad для работы, но это очень специфичная работа, в основном в консоли + хfce на минималках. И если до этого я всеми силами пытался избегать мака, то сейчас производители не оставили альтернативы.

                                                                                                            Кастомные решения всегда были, но это еще хуже чем стоковые, рынок сильно узкий, бренд неизвестный, и бабла в r&d вливают сильно меньше чем apple, dell, hp и прочие крупные производители ноутов.
                                                                                                              0
                                                                                                              бабла в r&d вливают сильно меньше чем apple, dell, hp и прочие крупные производители ноутов.

                                                                                                              не ради холивара, но что толку от вливаний в R&D, если ноуты получаются посредственные? Я уже у второго работодателя вижу патологическую любовь к корпоративным HP. И могу сказать, что это обусловлено совершенно не техническими причинами, а скорее тем, что раз заказываешь сервера HP, то вот тебе и ноутбуки в нагрузку. Это раз. Два — я не могу сказать, что те же хапэ ужасные ноутбуки — десктопный сегмент еще хуже, но эффективность работы на них по разным причинам сильно ниже, чем на аналогичных dell или маках. И это серьезно. Потому что ноутбук должен быть не только напичкан всякими крутыми r&d штуками и нести на себе крутой логотип крутого бренда, но и вообще быть нормальной, сбалансированной железкой. А крупным вендорам… пофиг. Они не этим берут. С другой стороны — да, есть поддержка, вероятность проблем минимальна, в отличие от безымянного Китая, ну, и всегда есть гарантия — вот была история, что у XPSок батарейка вспухает — но приходится вендору идти на попятную и менять или чинить несчастным владельцам устройство.


                                                                                                              Так что, повторюсь, по совокупности — я тоже перешел с thinkpad'ов на мак. (((( и пока альтернатив не вижу.

                                                                                                                +1
                                                                                                                Я скорее описываю тенденцию, что ноуты кроме эппла со временем становятся хуже (у «не эппл» конкуренция постоянная с китаем, и как следствие постоянно удешевление). И выходит что эппл выпуская минимально или вообще не модифицированное железо со временем просто стал лучше всех остальных. Хотя изначально эппл был в роли догоняющего.

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

                                                                                                                r&d наверное важнее больше в мобильном сегменте и только потом эти разработки должны попадать в ноуты.
                                                                                                                  +1

                                                                                                                  Linux нормально маки поддерживает? Или вместе с железом и софт сменили?

                                                                                                                    +1

                                                                                                                    В смысле нормально? Я не понимаю Вашего комментария? ОКей. Давайте с самого простого — нафига на мак ставить линукс? Если очень надо — докер есть, виртуалбокс тоже нормально работает. Предположу, что Вы бескомпромиссны, мак ось вообще не переносите и хотите полностью тюнить систему сами. Ну, окей — ставьте линукс, кто запрещает-то? Оборудование у маков вполне стандартное. Ну, может какие-то специфические возможности потеряете вроде шифрования дисков. Ну, и ладно.

                                                                                                                      +1

                                                                                                                      Речь шла о том, что железо у эппл хорошее, качественное, корпуса не скрипят и т. п.


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

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

                                                                                                                        В случае маков такого нет и никогда не будет


                                                                                                                        Речь шла о том, что железо у эппл хорошее, качественное, корпуса не скрипят и т.

                                                                                                                        Не хуже, чем у остальных. Но есть и серийные проблемы, о которых все знают.

                                                                                                                          +1
                                                                                                                          В случае маков такого нет и никогда не будет
                                                                                                                          С учётом того, что вам его даже по гарантии без MacOS чинить не будут (и нет, в данном конкретном случае это не прихоть Apple: у них там в MacOS костыли, необходимые, чтобы эта хрень без вентилятора не сгорела к чертям)… было бы странно ожидать скидку.
                                                                                                                        +2
                                                                                                                        Давайте с самого простого — нафига на мак ставить линукс?

                                                                                                                        Под линуксом может быть привычнее и удобнее.


                                                                                                                        Оборудование у маков вполне стандартное.

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


                                                                                                                        Ну и на макбук 2012-го, что ли, года у меня линукс таки не встал — видео не завелось. Но я не так много времени в это инвестировал, thinkpad достаточно хорош для меня.

                                                                                                                          +2

                                                                                                                          Я ставил на macbook pro ~2013 года, первый в общем с retina дисплеем. Именно по причине привычности. Все работало и тачбар и выход из спящего режима и wifi, но не сразу конечно. По мере выхода новых ядер все постепенно исправлялось.

                                                                                                                            +1
                                                                                                                            Thinkpad с IBM был очень хорош, с Lenovo пока еще достаточно хорош.
                                                                                                                  +1

                                                                                                                  У меня на старом ноуте была точно такая же ситация, но с виндой. Там в итоге ещё и SSD отваливался из-за перегрева.


                                                                                                                  Сейчас новый ноут — тьфу-тьфу, не включается.

                                                                                                                    +3

                                                                                                                    С одной стороны, у меня есть Thinkpad T560 — там всё работает из коробки, вплоть до сканера отпечатков пальцев (насколько это понятие применимо для генты — мне ни с чем не пришлось отдельно возиться).


                                                                                                                    С другой стороны, у меня есть знакомые с макбуком, который я иногда у них беру для мелких задач. Свежая прошка 2019-го года, процессор с 6 физическими ядрами и 12 логическими. За последний месяц я брал его два раза, и оба раза он вёл себя исключительно неудовлетворительно:


                                                                                                                    1. Надо было протестировать работу своего проекта под маком. Тесты проекта запускают 12 копий одного бинарника (по числу логических ядер) одновременно и что-то с этим делают. На своей линуксомашине я могу спокойно написать stack test и заниматься своими делами (слушать музыку, строчить комменты, сёрфать интернеты), не замечая, что там что-то в 12 потоков кряхтит. Макось от такого насилия, видимо, офигела, зависла секунд на 20 (даже курсор не двигался), потом пшикнула вентиляторами и выключилась.
                                                                                                                      А, ну и ещё стоило больших усилий узнать, что DYLD_LIBRARY_PATH не наследуется субпроцессами без отключения SIP, поэтому пришлось прописывать симлинк на либу в /usr/local/lib (и документировать это в README). Мак точно для разработчиков?
                                                                                                                    2. Надо было позвонить по google meet. Я почему-то думал, что под гентой оно обязательно не заведётся, и даже не пробовал зайти из-под браузера на своей машине. Только вот почему-то гуглохром под макосью при заходе на соответствующую страницу браузер наглухо вис (до перезагрузки, впрочем), так что пришлось звонить с мобильника.
                                                                                                                      Потом я таки рискнул и в следующий раз позвонил из-под генты — всё просто работает, от микрофона-звука до камеры.
                                                                                                                      0
                                                                                                                      Мак точно для разработчиков?

                                                                                                                      вполне. Опять же — не предполагается, что что-то сверх-тяжелое будет выполняться на ноутбуке, но какие-нибудь легкие тесты и отладка — почему нет. У DS'ов больше бомбит от того, что у им своим GPU-оптимизированные (CUDA) приложения локально не позапускать. Этот кусок рынка яблоко реально откровенно просрало, но, к справедливости, у всех DS'ов есть мощные самосборные машинки с 3+ видеокартами для того, чтобы датасеты с kaggle обсчитывать, куда они ходят удаленно по ssh — и тут опять встает вопрос — а действительно ли локально нужно иметь мощную машину.
                                                                                                                      Ну, и еще один момент — надо понимать — мы пишем код под POSIX (ну, типа переносимый между lin/win/mac) и тогда все ок, либо надо расчехлять докер или виртуалку, т.к. мак все-таки другая операционная система.


                                                                                                                      Только вот почему-то гуглохром под макосью при заходе на соответствующую страницу браузер наглухо вис (до перезагрузки, впрочем), так что пришлось звонить с мобильника.

                                                                                                                      активно пользуюсь — google chrome, meet, hangouts, zoom, skype, telegram и пр — проблем никаких нет

                                                                                                                  0
                                                                                                                  Есть хорошие по железу/цене ноутбуки с комбинациями типа SSD 512Gb + HDD 2Tb
                                                                                                                  Я не отрицаю их наличие. Просто среднестатистический человек не может их купить, не больше ни меньше.
                                                                                                                    0

                                                                                                                    Среднестатистический человек не может или не будет в Линукс, и ?

                                                                                                                      0
                                                                                                                      По вашему, если у человека нет денег на ssd, то он не будет ставить себе linux? Или может быть, если кто-то поставил linux, то он может предъявить сертификат работодателю для повышения зарплаты? Гениальная логика же! Вы не допускаете, что человек может поставить linux своим родственникам например, или же не видит смысла тратить на условные 500 долларов больше, только ради того, чтобы корпорации могли писать всё более требовательный код? Речь идёт не о покупке ssd когда он действительно нужен, например для современных игр или же сборки больших проектов, здесь идёт речь о том, что ВСЕ пользователи просто обязаны обновить свой пк только лишь по тому, что в календаре уже 2020 год?
                                                                                                                      Поэтому Поттеринг разумно выжидает, пока все оставшиеся некроманты не перейдут на SSD.
                                                                                                                      Вот уж действительно некромантия, прогресс ради прогресса. Вот интересно, а использование x86 приложений, это некромания в какой степени?
                                                                                                                        –3

                                                                                                                        Я себе недавно взял себе ноутбук — так в нём вообще нет возможности поставить HDD, только два M.2 SSD. В итоге поставил SSD на терабайт — обошлось мне это в 8 тысяч рублей, ни о каких $500 речи больше нет.

                                                                                                                          0
                                                                                                                          Сколько в сумме ноутбук стоил?
                                                                                                                            0

                                                                                                                            48 — ноутбук, 8 — ssd, 2.5 — модуль памяти.

                                                                                                                              0

                                                                                                                              Ух-ты, я как-то пропустил момент когда терабайтники SSD начали стоить чуть больше $100! Да, теперь для HDD реально осталось только одно применение — хранить видео-файлы и бэкапы.

                                                                                                                                0

                                                                                                                                Я так понимаю, это qlc. Там вопросы к скорости за пределами кэша и к надежности. Tlc всё-таки две сотни стоит.

                                                                                                                                  +1

                                                                                                                                  Нет, там TLC, стоят они сейчас порядка $120-130 за обычные модели, а $200 и выше — это уже топовые модели типа Samsung 970 PRO.


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

                                                                                                                                    +1
                                                                                                                                    Для хранения фильмов и музыки вполне годятся.
                                                                                                                                      +1
                                                                                                                                      Не годится. Даже драный SMR вполне себе выдержит лет пять на полке, а вот про QLC у меня есть пара вопросов.
                                                                                                                                        +1

                                                                                                                                        SMR-то выдержит, а механика?
                                                                                                                                        Стрессовая нагрузка (запуск) в разделившемся на фракции гидроподшипнике может передать привет. Особенно, если на нем тоже сэкономят.

                                                                                                                                          0
                                                                                                                                          Как показывает практика, если винт не останавливается, то он спокойно живёт долгие года по механике. А вот если его по десять раз в день мучить старт-стопом то да, мрут гады.
                                                                                                                                            +1

                                                                                                                                            Только вот винт на полке не попадает ни в одну из этих категорий.

                                                                                                                                              0
                                                                                                                                              Сейчас достал 2Тб, который на полке уже лет пять лежит — завёлся наура, читается прекрасно.
                                                                                                                                                +1

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


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

                                                                                                                                      0
                                                                                                                                      WD blue 1 tb, «TLC 3D NAND», цитируя маркет, от 8 с копейками тысяч.
                                                                                                                                        0
                                                                                                                                        Одни из худших ssd дисков на рынке, если верить тестам выносливости.
                                                                                                                                          0
                                                                                                                                          Когда-то OCZ Vertex был худшим в этих тестах, вон валяется в развалившемся ноуте — 10 лет отработал и ещё столько же сможет =)
                                                                                                                                          Да и гарантия у WD 5 лет на эти железки. Так что всё не так страшно. А данные можно и на самом надежной модели диска потерять — там как с динозавром вероятность.

                                                                                                                                          Так что всё не так страшно, если в десктоп/ноутбук втыкать. В серверах может и быстро умрет.

                                                                                                                                          Но да, TLC, а тем более дешевые — наименее надежные по тестам, это не новость. Хочется надежных — либо платите скоростью доступа, либо платите интелу, давно известный факт.
                                                                                                                                            0
                                                                                                                                            ocz в свое время дохли как мухи от багованого контроллера, насколько помню. WB blue просто нет доверия. Их контроллер очевидно говно, потому что у других тошибовская память умеет работать нормально, хотя сама по себе она тоже так себе. Смысл брать заведомо плохой вариант.

                                                                                                                                            А в серверах надо использовать диски для серверов, у которых резервные области большие, алгоритмы работы нормальные и скорость не падает в ноль, когда внезапно кто-то флашит каждую запись на диск.
                                                                                                                                              0

                                                                                                                                              У меня OCZ отлично работает с 2011 года. Осталось ещё 98% ресурса. А от багованного контроллера умер купленный чуть раньше Corsair x128.


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

                                                                                                                                                0
                                                                                                                                                Да сейчас вполне надежно уже все. Почему wd blue и смотрится так аномально. Он на 3d nand (хоть и от тошибы), не dram-less какое-нить поделие копеешное, а так плохо выступает. Просто привыкли, что ssd как правило выходят далеко за границы заявленного ресурса. В основном конечно самсунги приучили.
                                                                                                                                                  0

                                                                                                                                                  А чем dram-less не угодил? Для ноутбуков вполне нормальный вариант из-за более низкого энергопотребления. А по скорости особой разницы нет.


                                                                                                                                                  Ну а если у вас серьёзные нагрузки, то, скорее всего, у вас уже не ноутбук, а рабочая станция.

                                                                                                                                                0
                                                                                                                                                > Смысл брать заведомо плохой вариант.
                                                                                                                                                400 TBW для террабайтника — не самый плохой вариант, в общем-то. Особенно, когда не хочется нести интелу 18+ тысяч за десктопный ssd.
                                                                                                                                                А все остальные — те же сорта дерьмеца, про которые можно сказать, что когда-то там в каком-то году они или сыпались, или тормозили.

                                                                                                                                                > А в серверах надо использовать диски для серверов
                                                                                                                                                В серверах используют то, что на данный момент в конкретном данном сервере оправдано. И у террабайтных консумерских ssd на 1TB область применения в серверах сейчас есть, как была и у 512GiB, которыми забиты все бюджетные хостеры — и никто не жалуется.
                                                                                                                                                  0
                                                                                                                                                  400 TBW для террабайтника — не самый плохой вариант

                                                                                                                                                  По нынешним меркам плохой, если диск умирает ровно на этих 400. По тестам 250Гб версия сдохла после 82тбайт записи из 100 заявленных. Это позорный результат.

                                                                                                                                                  А все остальные — те же сорта дерьмеца

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

                                                                                                                                                  В серверах используют то, что на данный момент в конкретном данном сервере оправдано.

                                                                                                                                                  Естественно сервера разные бывают, только как правило под этим подразумевают что-то серверное по нагрузкам, для чего консьюмеровские диски никак не катят. Базы на них крутить себе дороже. Они свои скорости в таких областях не могут обеспечить, ибо контроллеры у них для других целей.
                                                                                                                                                    0
                                                                                                                                                    > По тестам 250Гб версия сдохла после 82тбайт записи из 100 заявленных.
                                                                                                                                                    Так пусть в гарантию отнесут, у 256 гарантия до 150 TBW, у террабайтника до 400 распространяется, в чём проблема?
                                                                                                                                                    У них SunDisk ultra 3D, который является тем же диском с другой наклейкой, 500+ надолбил. А у 3dnews WD blue 700+ отмотал тот же.
                                                                                                                                                    Бестолку судить по одному тесту на единственном сайте, тем более, когда есть совершенно противоположные мнения.

                                                                                                                                                    А самсунг привез 256Gb-платы в корпусе от террабайтника с серийником от террабайтника. Их тоже не покупать из-за одного случая?

                                                                                                                                                    > только как правило под этим подразумевают что-то серверное по нагрузкам
                                                                                                                                                    Не знаю, что у вас там за «правила», но серверов, которые обслуживают высоконагруженные БД в мире — единицы процентов (если не десятые процента). Девелоперских/тестовых серверов, хомячков с лампой на сотню тысяч запросов в день и файлопомоек — в разы больше (буквально). И там дешманские ssd отлично прижились. Потому что через 5 лет ты их тупо выкидываешь и меняешь на х4 по объёму. А помирать? Да нет, не помирают массово, иначе всякие hetzner-ы и OVH уже давно разорились бы.
                                                                                                                                                    Понятное дело, что есть задачи, в которых десктопным ssd не обойдешься — но их количество не позволяет даже близко заявлять, что чему-то там где-то там не место.
                                                                                                                                                      0
                                                                                                                                                      Samsung EVO 860 по TBW вам как нравится?
                                                                                                                                                        0
                                                                                                                                                        Я выше уже озвучивал, что нет смысла смотреть на TBW, если вы покупаете один единственный диск в свой личный комп.
                                                                                                                                                        Просто выбираете подходящий по цене диск от известных производителей — OCZ, WD, Corsair, Samsung, подставить_своё. Главное, чтобы была российская гарантия и возможность достучаться до неё.
                                                                                                                                                        Если задача более сложная и есть деньги — всегда покупаю Intel (впрочем, единственное место, где я купил intel лично себе — домашний сервер, ssd под систему).

                                                                                                                                                        У любого производителя бывают неудачные партии с браком, так что вероятность потерять данные — всегда 50%, если диск один. А даже самая минимальная тысяча циклов перезаписи для личного ПК — огромный ресурс, пара десятков лет минимум с учетом TRIM-а. По сути самые первые SSD из условно «современных» (2008-2010) ещё не начали массово умирать из-за израсходования ресурса перезаписи, если речь про ПК с обычными задачами.
                                                                                                                                                      0

                                                                                                                                                      Ну у меня за 73290 часов работы по данным контроллера суммарно записано порядка 22 ТБ данных. SSD не жалел совсем: и своп на нём, и торренты. Так что 400 TBW для меня — это достаточная величина.

                                                                                                                              0

                                                                                                                              Есть и попроще модели, типа 128+512. Я к тому, что HDD на домашних или рабочих компах ещё не редкость.

                                                                                                                            0
                                                                                                                            все вы делаете не так — странно иметь дисков менее чем не 10Т, а это уже не SSD (те я использую только в качестве кэша разве для ZFS)…
                                                                                                                          0
                                                                                                                          У вас в 2020 году HDD на десктопе?

                                                                                                                          У меня на десктопе SSD на 240 гигабайт и два харда на два терабайта в RAID1. SSD для разработки, / и почти всего ~, кроме папок с говорящим названием storage и music. Зачем мне почти полтерабайта музыки хранить на SSD, в конце концов?

                                                                                                                    0
                                                                                                                    Windows NT появился в 1993 году. Windows 2000 — в 2000.
                                                                                                                    И там уже была вполне вменяемая система запуска сервисов и довольно функциональный ServiceControlManager.
                                                                                                                    Неужели было настолько сложно взять это удачное решение (SCM API) за основу?

                                                                                                                    У него уже тогда было довольно много очевидных преимуществ над той системой, что тогда была в линуксе, расширенный контроль системы над состоянием сервисов и т.д.
                                                                                                                      +3
                                                                                                                      Он был настолько успешным, что появился nssm с характерным названием.
                                                                                                                      И по сей день отдельные виндовые сервисы (mdt monitor, например) при фейле зависимостей возвращаются с кодом 0 и не перезапускаются вне зависимости от настроек SCM.
                                                                                                                      Ну а чтобы собственный сервис добавить в SCM нужно либо перекомпилять всё, либо врапперы использовать. В общем, оно тоже не сахар, это ваше SCM API.

                                                                                                                        +2
                                                                                                                        А, ну и я в порыве графоманства забыл ответить на вопрос.
                                                                                                                        Сервис в винде — это отдельно-хитрый бинарник со своим энтрипоинтом и прочим. В линуксах демоны просто детачатся от терминала, в остальном это точно такие же бинарники, как и везде. SCM полагается на то, что логику управления сервисом будет реализовывать сама бинарь, sysvinit возлагает эту обязанность на инитскрипты, так как внутри бинари это будет привязано к определенной инит-системе, что противоречит духу платформы.
                                                                                                                          0
                                                                                                                          внутри бинари это будет привязано к определенной инит-системе, что противоречит духу платформы.

                                                                                                                          Это генерирует много ненужных костылей вокруг запуска этих скриптов.
                                                                                                                          И потом использование SCM вполне может быть опциональным — есть же виндовые программы, которые могут запускаться и как сервис, и как обычная программа.
                                                                                                                          Ну и да, совершенно необязательно повторять все косяки Win SCM. Я говорю о самой структуре управления сервисами, когда часть, отвечающую за репорт состояния сервиса, берёт на себя сам сервис.
                                                                                                                            +1
                                                                                                                            репорт состояния сервиса

                                                                                                                            Не в курсе чё там в SCM, но в systemd какой-то репорт таки есть через функцию sd_notify (впрочем, это таки требует линковки с libsystemd)

                                                                                                                              +3

                                                                                                                              Не требует. sd_notify() всего лишь пишет посредством send() в открытый UNIX socket, номер которого содержится в переменной среды NOTIFY_SOCKET, то что он пишет вполне текстовое, типа "READY=1\n" или "STATUS=Failed...\n".

                                                                                                                              0
                                                                                                                              > когда часть, отвечающую за репорт состояния сервиса, берёт на себя сам сервис.
                                                                                                                              Так а нет понятия «сервис» в этих ваших линуксах. У демонов детачим консоль, а сервисы — это демоны с каким-то дополнительным функционалом для работы с инит системой (какой именно?) И через что взаимодействовать будем — dbus, али ещё что? (upd: чуть выше зашла речь про сокеты, и это действительно был вариант)
                                                                                                                              В 90-х всего этого попросту не существовало, вероятно поэтому и ограничились скриптами.
                                                                                                                        +8
                                                                                                                        Первое впечатление о systemd было неоднозначным, было много негатива, а порой даже агрессивных выпадов в духе да как они могли покуситься на святое, было много разборов багов и неожиданных поведений во вполне ожидаемых событиях, но почему-то systemd считал по другому.
                                                                                                                        Решился в итоге на обновления виртуалок с debian 7 только спустя год после выхода 8ки jessie, и в принципе не пожалел. И следом обновил совсем уж старые centos6 до centos7. Разницы конечно глобально не заметил, upstart на центоси и runit на дебиане функции свои выполняли исправно, единственное, что стало плюсом, одинаковый конфиг сервисов на любой ОС. Хотя понравилось что ушли от своеобразной системы логирования у runit, всё стало логироваться в syslog.
                                                                                                                        Но как я понимаю, что это до поры до времени, journalctl пока не повсеместно используется, пока в 10м дебиане и центос8 логи пишутся по старинке, но вот в домашней федоре уже просто грепом по файликам не пройтись, и это не очень нравится. Конечно, дело привычки, но всё же.
                                                                                                                        По стабильности, за 4 года столкнулся всего два раза что сервисы переставали отвечать на команды, не запускались, не останавливались. Оба раза помогло systemctl daemon-reexec, без дорогостоящей перезагрузки всей системы.
                                                                                                                        Из мелочей — не работает опция CapabilityBoundingSet, например CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права, решилось установкой через setcap непосредственно на бинарник.
                                                                                                                        И в итоге — по моему опыту использования как раз основная претензия к journalctl, если остальные компоненты systemd занимаются ровно тем, чем должны по идеологии PID1, на мой взгляд как раз логирование выходит за эти рамки.
                                                                                                                          +2
                                                                                                                          в домашней федоре уже просто грепом по файликам не пройтись

                                                                                                                          Это как раз просто — journalctl --since today | grep ... — ничем не хуже, даже в чём-то лучше (с учётом других опций).


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

                                                                                                                            0
                                                                                                                            — Проблема с journald (одна из) совсем в другом, на самом-то деле — он пишет всё что есть, нет возможности фильтрации до записи (кроме как по уровням), со всеми неудобствами (очень много мусора)…
                                                                                                                            Ну вот, собственно, это и причиняет неудобства. Я не совсем корректно выразился, что хотел сказать. С этим разобрался, конечно, с флагами, но то что пишется всё в одну кучу, не айс. Смешались в кучу, люди, кони, и всё другое. Это нехорошо. И всё равно, даже есть такая возможность, на основной процесс, который рулит всей системой, вешать логирование неправильно, причём без права разделения.
                                                                                                                              0
                                                                                                                              И всё равно, даже есть такая возможность, на основной процесс, который рулит всей системой, вешать логирование неправильно, причём без права разделения.

                                                                                                                              на самом деле правильно. Вот, предположим, запись в лог у вас блокирующая. Место на диске кончилось. Ваши действия? Ждать пока логротейт придет?


                                                                                                                              Кстати, в убунтах этих ваших — выхлоп journald бережно rsyslog'ом режется на файлы и складывается в текстовом виде в /var/log/*.log (auth, syslog etc.). Т.с. для легаси админов, которые умеют только в текстовые файлики. Все для Вашего удобства, т.с.

                                                                                                                                +3
                                                                                                                                на основной процесс, который рулит всей системой, вешать логирование

                                                                                                                                Никто там ничего не вешает.


                                                                                                                                root       46465  0.0  0.7 133572 64680 ?        Ss   May28   0:16 /lib/systemd/systemd-journald

                                                                                                                                Это отдельный процесс вообще-то.


                                                                                                                                Запустите systemd-cgls — увидите много интересного.

                                                                                                                                +1
                                                                                                                                но редиска Поттеринг сопротивляется этому всеми фибрами, утверждая что писать нужно всё без исключений (даже тонны мусора), а фильтровать исключительно при просмотре.

                                                                                                                                если подумать, то он прав...

                                                                                                                                  +10

                                                                                                                                  Подумайте об устройствах типа RPi с SD-картами, где какой-то сервис пишет неотключаемый дебаг в журнал минимум раз в секунду, причём на уровне info вместе с иногда (и очень редко) нужными сообщениями.


                                                                                                                                  Или о системе где сотня сервисов и каждый (ре)стартует посредством таймеров раз в несколько секунд — зачем мне знать что они start/stop, если мне гораздо важнее знать как раз наоборот — что кто-то этого вовремя не сделал?


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


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


                                                                                                                                  Ну и наконец… Есть всё-таки разница, фильтровать вывод с чего-то размером в 100 мегабайт или 10 гигабайт, особенно если в последнем случае полезной информации не более чем 100 мегабайт, но вам нужен диск побольше просто ради мусора (и хорошо если это не SSD/SD).


                                                                                                                                  Что примечательно — на гитхабе несколько многолетних веток на эту тему, ясно что фича нужная и полезная, но позиция Поттеринга — "я не убежден что это нужно". Ушли буквально годы чтобы в сервисах можно стало перенаправлять вывод в файлы или сокеты (вместо journald), на фильтрацию, наверное, вообще уйдут десятки лет… И проблема совсем не в том чтобы это сделать (pull requests были) — проблема в позиции "это неправильно, нужно писать всё и не давать никому выбора". Чем-то напоминает djb с его errno...


                                                                                                                                  Если почитать его мнения на этот счёт — да, в идеальном мире это должно делаться на стороне сервиса — и фильтрация, и прочее, journald не может знать что важно а что нет, но увы, мы живём в реальном мире и некоторые (особенно очень древние) сервисы не переписать и ненужные логи не отфильтровать, разве что посредством внешнего приложения типа multilog, что вносит другие проблемы.


                                                                                                                                  PS: Извините, наболело. По факту, это единственная насущная проблема связанная с systemd… всё остальное, при всех недостатках, всё же сильно перебивается достоинствами.

                                                                                                                                    –1

                                                                                                                                    А повесить свой фильтр на свой сокет, писать в него, а он уже после фильтрации будет в журнал?

                                                                                                                                      +2

                                                                                                                                      Если вы не желаете чтобы ВСЁ писалось на диск/флешку — можно легко отключить запись бинарных логов journald на non-volatile storage и хранить логи только в оперативной памяти. Мне мнится, что на типичном десктопе с или raspberry pi почти всегда логами с прошлых запусков системы можно пренебречь. Опционально можно копировать логи из journald в какой-нибудь классический syslog демон, его силами фильтровать ненужное, а потом писать что хочется, куда хочется и как хочется. Я лично, к примеру, на серверах локально пишу таким образом нужные кусочки логов. И доволен аки слон.
                                                                                                                                      Кстати, у journald эта опция по дефолту выставлена в "Auto", при этом значении на диск логи пишутся в случае существования пути /var/log/journal/. Если пути нет — пишутся только в память. Поэтому на всяческих rpi можно просто сразу сделать rm -rf /var/log/journal и забыть о проблеме.


                                                                                                                                      Ну и напоследок хочу заметить: мне кажется крайне неправильно считать journald этакой плохо спроектированной и недостаточно фичастой заменой классическим syslog демонам или специализированным решениям для сборки и консолидации логов на отдельной хранилке. Воспринимайте journald как нечто, что собирает в одном месте выхлоп от всего, что его в принципе производит, заодно авторитетно добавляя поля типа pid/name источника. А дальше это нечто позволяет делать с собранным то, что вам нужно + даёт возможность посмотреть все логи единым полотном, что нередко очень и очень удобно.

                                                                                                                                  +3
                                                                                                                                  CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права

                                                                                                                                  Он не для выдачи прав, а для ограничения возможностей. Например, указанная строка сделает так, что процесс и его дети не смогут делать, всё остальное (что через capabilities рулится), даже если от рута работают.


                                                                                                                                  Для выдачи прав есть AmbientCapabilities=, например:


                                                                                                                                  AmbientCapabilities=CAP_NET_BIND_SERVICE

                                                                                                                                  Это не в systemd дело, просто подсистема capabilities так работает.

                                                                                                                                  –13

                                                                                                                                  Из всего сказанного понятно, что главным недостатком BSD like скриптов, sysvinit,…, является то, что они написаны не Поттерингом.


                                                                                                                                  Оно и верно, зачем изучать разумное и совершенствовать его? Ведь надо создавать новое, отрицать старое, мешать в одну кучу udev и system start/stop, нарушать принципы, вести народ в будущее.


                                                                                                                                  У нас нет авторитетов! Мы делаем новую жизнь, нам понятен формат winini файлов.


                                                                                                                                  Ура, товарищи!

                                                                                                                                    +7

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

                                                                                                                                      0
                                                                                                                                      Зря вы так думаете. Разумеется, rc скрипты поставляются разные, некоторые разработчики не уделяют должного внимания start/stop скриптам, поставляемым в составе их продуктов. Так было всегда, это примерно так же, как поставлялись m4 скрипты в составе библиотек, когда автор просто копирует чужие скрипты и слегка перерабатывает их под свои нужды (при этом источник выбирается не всегда самый правильный).

                                                                                                                                      Однако сообщество, вместо того, чтобы написать автору какой-либо библиотеки предложение по улучшению в их скриптов, решило что лучше отдать все на откуп pkgconfig (который, кстати тоже глючит немерянно).

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

                                                                                                                                      И это нормально, это же OSS сообщество, где люди помогают друг другу, а не враждуют.

                                                                                                                                      Однако сейчас о такой кооперации остается только мечтать. Общество становится все более токсичным и люди скорее склонны отрицать старое разумное, ввиду невозможности понять, и создавать альтернативы, которые кстати зачастую убивают лучшее и привносят новые ошибки. Так было во время введения pkgconfig, так было во время создание systemd, так же будут поступать с Autoconf, Automake путем их замены на CMake, ninja+meson,…

                                                                                                                                      Но я надеюсь на то, что OSS сообщество не превратится в террариум.
                                                                                                                                        0
                                                                                                                                        Посмотрите на портянку rc скрипта от GitLab. Я, например, адаптирую его под Slackware и не жалуюсь. Это нормально.
                                                                                                                                      0

                                                                                                                                      Full disclosure: я терпеть не могу systemd. Но статья понравилась, хоть и написана очевидно предвзято, но автор и не скрывает. Поэтому просто немного прокомментирую статью.


                                                                                                                                      начиналось как просто PID 1 и стала тем, что я бы назвал middleware современного дистрибутива Linux

                                                                                                                                      И это плохо само по себе. Тем более, что опыт показывает, что в этом нет реальной необходимости: у меня Gentoo, причем даже не на OpenRC а на Runit, и при этом много лет используется udev (точнее eudev) и вот на днях перешёл на logind (точнее на elogind). Как видите, нет большой проблемы выделить полезные и нужные компоненты из systemd — или, говоря иначе, нет и небыло реальной технической (в отличие от политической!) необходимости изначально слеплять их в одно целое.


                                                                                                                                      В атмосфере беспорядочного хаоса было предприняты несколько попыток решить проблемы sysvinit:

                                                                                                                                      Вы забыли упомянуть некоторые более достойные альтернативы, вроде того же OpenRC, Runit и S6 — а без этого обзор, мягко говоря, не даёт реальной картины.


                                                                                                                                      Но на сегодня самой известной альтернативой (кроме systemd) является, пожалуй, Upstart.

                                                                                                                                      Да неужели?!
                                                                                                                                      image


                                                                                                                                      Это и произошло. Debian Jessie вышла с systemd в качестве менеджера системы, и вслед за Debian …

                                                                                                                                      … появился Devuan, который "Debian без systemd". Википедия говорит, что есть 53 дистрибутива без systemd. Я это к тому, что из Вашего описания складывается впечатление, что последние бастионы сопротивления пали на дебиане, и везде воцарился systemd… так вот, это не так.


                                                                                                                                      С целью решить эти проблемы и был представлен journald:

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


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

                                                                                                                                      Это просто слова. А факты можно увидеть в базе CVE: 56 записей.


                                                                                                                                      Платформа systemd, на самом деле, гораздо проще традиционного Linux, потому что она объединяет системные объекты и их зависимости в юнитах с простым синтаксисом конфигурационных файлов.

                                                                                                                                      Это бред, уж простите меня за прямоту. Юнит-файлы systemd проще rc-скриптов sysvinit — безусловно. Но сам systemd крайне сложен, и ограничить его изучение синтаксисом unit-файлов можно ровно до первой проблемы… а потом придётся разбираться с самим systemd, и это будет намного сложнее отладки rc-скриптов sysvinit, OpenRC и тем более run-файлов Runit.


                                                                                                                                      В целом, systemd, возможно, настолько прост, насколько системный менеджер может быть простым.

                                                                                                                                      Посмотрите на Runit или S6, чтобы не было потом стыдно за такие заявления.


                                                                                                                                      число багов довольно мало для такого ключевого компонента ОС

                                                                                                                                      1200+ issues, из них 89 открытых багов… для такого ключевого компонента ОС — это просто неприемлемо!


                                                                                                                                      Для сравнения, у OpenRC 61 issue, из них поиск по слову bug выдаёт 14 (и не факт, что всё это реальные баги OpenRC, а 89 вышеупомянутых багов systemd имеют метку баг поставленную разработчиками systemd, т.е. это признанные баги). Про Runit сказать сложнее за отсутствием его на гитхабе, но насколько мне известно багов в нём нет. У S6 сейчас открыт 1 issue, и да, это баг — но баг сборки.


                                                                                                                                      В целом, Ваши слова являются типичным проявлением Стокгольмского синдрома.


                                                                                                                                      это новая эпоха в истории экосистемы Linux

                                                                                                                                      Ага. Позднее её назовут "тёмные века". :)

                                                                                                                                        +2
                                                                                                                                        рунит c 2014 года не обновляется, конечно стабильность есть. Но иногда нет уверенности как рунит поведет себя в паре системд, в проде как-бы нужна стабильность, поэтому рисковать нет особо желания. Поттеринг реально опасный тип, поэтому и приходится на нативный в дитрибутив запуск переходить. Моя бы воля, на дебиане7 бы до сих пор сидел, но ядро уже по тех требованиям не подходит. Почти смирился уже )
                                                                                                                                          +1

                                                                                                                                          Нормально он себя ведёт. Если его просто запустить и больше средствами systemd не трогать.


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


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

                                                                                                                                            0
                                                                                                                                            потому что всё, что он делает — это запускает докер, а всё остальное на этом сервере запускается внутри докера.

                                                                                                                                            это потому что у Вас нет специфических задач. Скажем, такой пример. Лежат файлы на NFS. Вы можете его подмонтировать как systemd mount — это правильно (либо сделать как-то иначе, но лучше не стоит). Далее выясняется, что докер контейнеры не умеют в зависимости. Вы их оборачиваете в системди юниты и выстраиваете цепочку перезапуска. Либо тащить nfs клиента в каждый докер образ (фу). Если же цепочку не выстроить — будет очень простая история, что протекут какие-нибудь дескрипторы, где-то внутри что-нибудь отвалится и вероятно, что Вы даже про это не узнаете, разве что по каким-то косвенным признакам.

                                                                                                                                              0

                                                                                                                                              Вы берёте сложный инструмент и пытаетесь решить простую проблему сложным способом, раз уж инструмент даёт такую возможность. А в реальности всё намного проще: сетевые диски нужно монтировать до запуска всех сервисов, включая докер. И, разумеется, их не нужно отмонтировать в процессе работы. Всё, проблема зависимостей решена, точнее её просто нет. Просто представьте себе, что этот сетевой диск — это volume на AWS. Да, он сетевой. Нет, он есть всегда, доступен сразу при загрузке, и отключать его в процессе работы никто не будет — потому что он притворяется локальным диском, как и должно быть. (А если будет — то он знает, что делает и какие будут последствия.)

                                                                                                                                                +4

                                                                                                                                                Только вот, во-первых, у вас не aws, во-вторых, я и не предлагаю его отмонтировать на ходу. Я ещё в здравом уме. Но вот залипнуть клиент nfs вполне может. Сетевые проблемы, скажем. И тогда придется перемонтировать. Дальше — по моему сообщению.
                                                                                                                                                Т.е. по существу — вопрос в том как разбита система на уровни и кто за них отвечает.

                                                                                                                                                  0

                                                                                                                                                  Если он залип в процессе работы — это уже никакого отношения к зависимостям между сервисами не имеет, потому что в этот момент зависящие от NFS сервисы уже давно запущены (и тоже залипли на попытке I/O). Перемонтирование в этих условиях не должно приводить к перезапуску зависимых сервисов, они просто штатно получат ошибку от ядра и обработают её как для них это правильно — повторив операцию I/O, например.

                                                                                                                                                    0
                                                                                                                                                    обработают её как для них это правильно — повторив операцию I/O, например.

                                                                                                                                                    не будь запущены в докере, кек

                                                                                                                                                      0

                                                                                                                                                      Чем им помешает докер повторить операцию I/O?

                                                                                                                                                    0
                                                                                                                                                    Но вот залипнуть клиент nfs

                                                                                                                                                    ЕМНИП, 20+ лет назад эту проблему эффективно решал amd и всё такое.
                                                                                                                                                    0

                                                                                                                                                    Вот не факт, что всё надо монтировать на этапе загрузки по сути. Не все сервисы должны стартовать автоматом, а держать маунт удалённой ФС на всякий случай — чревато

                                                                                                                                                      0

                                                                                                                                                      Вы правы. Всегда можно усложнить постановку задачи до такой степени, что без сложного инструмента с ней не справиться. Но, если честно, как часто лично у Вас на практике возникала такая ситуация — есть сервис, который не должен запускаться при загрузке сервера, сервису нужен NFS, который так же не должен монтироваться при загрузке сервера, и при этом есть реальная необходимость автоматически подмонтировать NFS в момент, когда админ ручками запустит сервис? Мне вот ни разу.

                                                                                                                                                        0

                                                                                                                                                        "Не должен монтироваться" — это просто соображение рациональности по нескольким критериям в том цисле уменьшение области воздействия потенциальных уязвимостей.

                                                                                                                                              –6

                                                                                                                                              Вас, как и меня будут дизлайкать. Это нормально. Если вы не в секте, то будет так.

                                                                                                                                                +7

                                                                                                                                                Проблема не в том, что кто-то в секте, а кто-то нет. Г-н powerman выказывает свое личное мнение, через призму своего личного искажения реал