Comments 115
До сих пор не смог до конца разобраться, почему некоторые сервисы не стартуют, правила iptables то работают, то нет, saned вот вдруг отвалился, приходится сканировать через scanimage.
До этого 10 лет все работало, пережило кучу апгрейдов, а тут вдруг перестало…
Почему обычные админы localhost-а не имеют возможности
Но есть же и плюсы, опыт управления localhost можно использовать
для управления любой машиной с Linux и даже не нужно разбираться что там
за дистрибутив.
Уточните, пожалуйста, какие баги раздражают.
И был ли открыт по ним issue до вас или вами?
Проблема известная и распространённая, последний раз когда я её смотрел она де факто была «won't fix».
У меня возникают вопросы:
— Нафига systemd вообще запомил guid ничего у меня не спрашивая?
— Почему невозможность примотнировать диск — фатальная ошибка?
Вообще, systemd как-то излишне похож на Nero Burning ROM и ASDSee последних версий перед тем как они канули в забвение.
Про guid раздела вы правы. Запоминать их не надо, но systemd зачем-то это делает. Текст сообщения был вроде бы как «failed to determine partition table type» Лечением проблемы, соответственно, было найти файл со списком разделов и удалить лишнюю запись (и это были не команды для mount, а какой-то кастомный формат)
Я могу попробовать воспроизвести эту ошибку, если вы настаиваете.
Ответ здесь https://habr.com/post/431202/#comment_19454844
Воспроизведите, давайте посмотрим, что там происходит. Сколько я дисков не переподтыкал, ничего такого не наблюдал. Ни в бареметалле (и ноутбуках), ни в виртуализированной среде.
guid и uuid — это синонимы
Согласно спецификации UEFI, в GPT Partition Entry есть PartitionTypeGUID и UniquePartitionGUID
То, что вы описали, никак не имеет отношения к systemd.
Это больше похоже на особенности работы UEFI, возможно даже особенности отдельных производителей железа. Например у меня одна мат.плата MSI при некоторых похожих условиях, самостоятельно удаляет запись загрузчика Linux и
устанавливает дефолтным загрузчиком Windows.
Собрав по кусочкам информацию от вас. Я пришёл выводу..
В данном случае systemd пытался задействовать механизм "The Discoverable Partitions Specification", для автоматического определения разделов.
И вот почему:
The OS can discover and mount the necessary file systems with a non-existing or incomplete /etc/fstab file and without the root= kernel command line option.
Итог: /etc/fstab нет или не полный, опция ядра root= не указана, разделы по спецификации вы явно не настраивали. Но systemd как всегда крайний.
Linux 3.16.7-53-desktop
openSUSE 13.2 (Harlequin) (x86_64)
Опция root= действительно не указанна, но fstab на месте. .mount-файлов в /etc/systemd нет
Разделы вручную я не настраивал потому, что либо за меня это делал инсталлер, либо я это делал через интерфейс Yast'а.
А крайний systemd именно потому, что отвечает за монтирование разделов при загрузке.
Но когда случайно во время работы узнаешь, что в systemd есть свой cron, свой ntp и ещё куча своих дублированных вещей, которым опять надо заново учиться из-за чьих-то фантазий… То немного пригорает :(
Но хочется изучать новые вещи, а не разбираться почему certbot использует крон от systemd, а не просто создал свое задание в /etc/cron.d/.
Вернее, даже так — мне и это интересно; ведь есть же причины, почему это создали и используют.
Но клиент ожидает [и обычно готов платить именно за это], что я просто поставлю и настрою за озвученное время инструмент. А вместо этого я вдруг узнаю что должен искать как смотреть таймеры в systemd (systemctl list-timers --all) и где редактировать таймер для certbot (/lib/systemd/system/certbot.timer).
И теперь я должен держать в голове два очень похожих инструмента, и проверять больше вещей.
А мог бы в это время почитать, например, чем firecracker лучше docker-а. Что для меня гораздо интереснее, чем изучение путей в systemd :))
А по факту — чтение док и выяснение почему в системе 2 крона и как редактировать задания для нового, потому что какой-то пакет стал вдруг использовать его.
Я не верю в теории заговора и поэтому полагаю, что причины были в недостатках sysvinit и прочих СИ.
Ага. Основным из которых был, конечно же, фатальный недостаток. И, кстати, я лично абсолютно уверен, что существование заговоров это факт, а не теория — это довольно очевидно. Не знаю, имел ли заговор место в случае systemd, но я бы этому не удивился, иначе довольно сложно объяснить как его сумели быстро пропихнуть почти везде, не смотря на сильное сопротивление сообщества.
Созданная в 1983 г. sysvinit не умела решать ряд важных задач, таких как:
Ну, кроме sysvinit полно других нормальных систем, например runit из простых и s6 из навороченных.
- параллельный запуск процессов;
Конечно, линукс же перегружают постоянно, скорость запуска системы — это самое главное.
- обнаружение съемных носителей;
Действительно, они ведь съёмные, поэтому их постоянно втыкают в середине процесса загрузки… нет? Странно… а почему тогда об этом должна беспокоиться система загрузки?
- активизация сервисов на основе сокетов;
Ровно так же ненадёжна, как и любой другой метод. Если сервис начал слушать порт — это вовсе не означает, что он не упадёт тут же, и в принципе будет обслуживать запросы. Это типичный пример решения несуществующей проблемы — идея неплохая, но реальной пользы от неё мало, и уж точно она не стоит той цены, включая конфликты в сообществе, которую уплатили за внедрение systemd.
- надежно контролировать зависимости между различными процессами и службами;
И снова бессмысленная фича, решающая несуществующую проблему. Да, есть начальный этап загрузки, где нужно соблюдать последовательность действий — но на этом этапе всё-равно мало смысла что-то делать одновременно. И есть следующий этап, где зависимости между сервисами не имеют значения — максимум, сэкономится секунда на перезапуске сервиса, чья зависимость не успела запуститься до него, плюс вывод одной строки в лог о причине перезапуска. Беда-беда.
- раннее логирование событий через /dev/log.
Честно говоря, я понимаю, почему логи терять нельзя. Чего я не понимаю, так это почему у меня сервис syslog (точнее, выполняющий эту роль socklog-unix) под runit запускается больше десятка лет на куче серверов одновременно со всеми остальными сервисами, без контроля зависимостей и всего такого, и никогда это не стало причиной каких-либо проблем. Ой, стойте, понимаю — systemd опять решил несуществующую проблему.
И снова бессмысленная фича, решающая несуществующую проблему. Да, есть начальный этап загрузки
При чём тут загрузка?
systemctl restart foo.target — перезапускает сразу несколько связанных сервисов. Пример из жизни #1: приложение на Python/Django с воркером Celery, код единый, при деплое нужно перезапустить оба сразу.
Пример из жизни #2: мы запускаем oneshot юнит от юзера (с ограничениями ProtectSystem=strict, сброшеные capabilities), но нам надо после того, как он отработал, сразу же автоматически запустить другой oneshot юнит от рута без ограничений. Делается с помощью зависимости After=bar.service. Либо опять городить нечитаемый bash скрипт.
Запускаем systemd-cgls — сразу видна картина, что запущено, для чего. Особенно если зашли на чужой сервер и надо за 60 секунд понять, что там работает. При этом неважно, это Debian, Ubuntu, Centos, RHEL, всё одинаково, все процесы отсортированы по группам. Кто у нас ещё умеет cgroups использовать по полной? runit умеет?
его сумели быстро пропихнуть почти везде, не смотря на сильное сопротивление сообщества
Потому что унифицирует кучу вещей, приводит из в порядок и сближает разные дистрибутивы. А омлет нельзя приготовить, не разбив чьих-то яиц.
при деплое нужно перезапустить оба сразу
sv t myservice1 myservice2
Либо, что встречается намного чаще: docker stack deploy -c myservice.yml myservice
сразу же автоматически запустить другой oneshot юнит от рута без ограничений
Просто любопытно, что конкретно делают эти юниты, откуда такие странные требования? И не тот ли это случай, когда из-за того, что инструмент даёт возможность делать странное мы начинаем это странное делать, вместо того, чтобы подумать лишние пять минут и сделать нормально?
Либо опять городить нечитаемый bash скрипт.
А почему, собственно, не читаемый? На баше можно писать вполне читаемо, и на нём написано очень-очень много, сколько бы фич не добавляли в systemd он всё-равно не сможет заменить все баш-скрипты на конфиг-файлы.
При этом неважно, это Debian, Ubuntu, Centos, RHEL, всё одинаково, все процесы отсортированы по группам.
Уверяю Вас, есть множество серверов, на которых systemd нет. С тем же успехом я могу сказать, что заходя на любой из моих серверов похожую картину можно увидеть запустив srvstat, а вот systemd-cgls на этих серверах выдаст только "command not found: systemd-cgls".
Кто у нас ещё умеет cgroups использовать по полной? runit умеет?
Нет. Докер умеет. И именно в докере обычно деплоятся все наши проекты. А использовать cgroups для системных сервисов вроде ssh, cron и syslog… можно, если получаешь это из коробки как в systemd, но, если честно, какого-либо реального эффекта на их работу или работу системы в целом наличие или отсутствие cgroups для этих сервисов — не оказывает. Иными словами, как я уже писал — очередная бесполезная фича, классная на первый взгляд, но на практике ничего не меняющая.
sv t myservice1 myservice2А потом появился myservice3, про него забыли и т.п. И про докер не надо, это уже другой уровень абстракции.
Просто любопытно, что конкретно делают эти юниты, откуда такие странные требования?
Ничего странного. Это случай из жизни — запускаем dehydrated для обновления сертификатов Let's Encrypt. Т.к. ему не нужны особые права, то запускаем от юзера. Потом надо от рута запустить reload сервисов, где сертификаты используются — для этого второй юнит, связанный с первым.
sudo? Ну ок, а если хочется ему ограничить права, например так:
ProtectSystem=strict
PrivateDevices=true
ProtectKernelTunables=true
ProtectControlGroups=true
CapabilityBoundingSet=
PrivateTmp=true
ReadWritePaths=/var/lib/dehydratedОпять же, вспоминаем, что unit не может быть запущен параллельно два раза, что сплошь и рядом встречается при запуске из крона (да, для этого надо ещё костылей городить, проверять pid файлы и т.п.)
сколько бы фич не добавляли в systemd он всё-равно не сможет заменить все баш-скрипты
Задачи заменить все баш скрипты никогда не ставилось.
похожую картину можно увидеть запустив srvstat
А user.slice как вы увидите? Или «это не надо»? Напоминаю, что systemd загоняет все процессы (кроме кернел тредов, конечно же) в какой-то вменяемо названный cgroup.
Докер умеет.
Про докер речь не идёт.
реального эффекта на их работу или работу системы в целом наличие или отсутствие cgroups для этих сервисов — не оказывает
Со временем все системные процессы, я надеюсь, будут переписаны с использованием cgroups для ограничения доступа, со сбросом не нужных для их работы capabilities, с фильтрами syscall'ов и тогда мы получим более надёжную и секьюрную систему «из коробки». Сейчас так обычно не делается, потому что на баше это выливается в десятки строк.
А ещё есть systemd.resource-control — как вы в скрипте ограничите I/O процесу? Или макс. количество тасков в cgroup?
Конечно, всё это делается на баше, но скрипт всё растёт и растёт.
А потом появился myservice3, про него забыли и т.п.
Ровно с тем же успехом можно забыть прописать зависимость между unit-файлами.
И про докер не надо, это уже другой уровень абстракции.
Почему, собственно? Докер делает ровно то, что Вы тут описываете — запускает и перезапускает сервисы, группами, изолирует их, показывает текущее состояние, etc. И при этом он не пытается заставить нас вообще всё делать только через него.
Ещё раз.
Есть загрузка системы и запуск системных сервисов вроде ssh/cron — это одна задача, и для этих сервисов нет заметной пользы от использования изоляции, сложного контроля зависимостей, etc. Это — факт, подтверждённый всеми существующими серверами без systemd.
А есть другая задача — запуск наших собственных приложений/сервисов, нередко написанных достаточно быстро/грязно, с запутанными внутренними зависимостями, etc. Такие сервисы намного эффективнее деплоить в формате контейнеров, и запускать под докером/k8s, с поддержкой cgroups, управлением сложными внутренними зависимостями, ограниченным root, etc.
Можно запихнуть в systemd первую группу, но видимой пользы от этого нет. Можно запихнуть в systemd вторую группу, видимой пользы будет много, но если вместо этого запихнуть их в docker — пользы будет ещё больше, чем от systemd.
при запуске из крона (да, для этого надо ещё костылей городить, проверять pid файлы и т.п.)
PID-файлы проверять не нужно — помимо прочего, это не надёжно. Обычно всё, что для этого требуется, это утилитка из runit (или аналогичная из daemontools/s6) использующая банальную файловую блокировку и делающая exec в заданную команду:
* * * * * chpst -L .lock mycommand …Почему, собственно? Докер делает ровно то, что Вы тут описываете — запускает и перезапускает сервисы, группами, изолирует их, показывает текущее состояние, etc. И при этом он не пытается заставить нас вообще всё делать только через него.
Еще как заставляет!
Если у меня есть бинарник — я его могу запустить как демона хоть через sysvinit-скрипт, хоть через systemd-юнит, хоть через крон. Если у меня есть докер-образ — я могу запустить его только докером.
С другой стороны, если у меня есть systemd, я могу с его помощью запустить любой бинарник. Если у меня есть докер — мне надо упаковать этот бинарник в образ, для чего требуется достать базовый образ чистой системы и выяснить все зависимости бинарника.
Это очень хорошо работает с приложениями на go, которые полностью инкапсулировано зависимости. С остальными — хуже, но тоже можно
При чем я еще могу и запускать свои контейнеры, без докера, для всяких тестов пробовал systemd-nspawn, чертовски удобная пепяка. Хотя для продакшена предпочитаю lxc для контейнеров.
Вы сейчас шутите?
Докер как раз ЭТУ проблему не решает.
Все равно приходится обмазываться внешними средствами: от баш скриптов и докер-компоузов до полноценных оркестраторов типа куба
И, да, докер-контейнеры можно описывать как системд юниты. Вполне себе best practice
На всякий случай поясню: пихать софт в докер — хорошая (в целом) идея. Можно контейнеры вообще на чем-то типа atomic или coreos гонять — ещё лучше. Но сам по себе он (docker) решает одну единственную задачу.
docker swarm вполне встроенный способ это делать.
Почему это? Я отлично использую swarm в рамках одного сервера, очень удобно для небольших проектов, которым нужно несколько контейнеров.
Касательно зависимостей. Предположим, что у Вас есть набор контейнеров:
* Базы данных
* Миграции
* Тесты
* Само приложение.
Решите задачу:
* Базы должны быть запущены постоянно
* После старта баз или по триггеру от пользователя должны накатиться миграции
* После миграций — стартуют тесты
* Если тесты успешные — должны стартануть контейнеры с приложением
В рамках куба это можно красиво.
В остальном — пришлось мудрить с хелсчеками и баш обёртками.
Я уж не говорю, если пришлось бы какой-либо контейнер запускать по таймеру (крон, да?)
Ес-но не хочется оставлять контейнеры после того, как они выполнили свою функцию. Но это и ставит крест на запуске докер-компоуз с ключом --abort-on-exit
- Базы должны быть запущены постоянно
docker stack deploy не будет перезапускать контейнер при перевыкате сервиса, если описание конкретно этого контейнера не поменялось в новой версии сервиса.
- После старта баз или по триггеру от пользователя должны накатиться миграции
Зачем так запутанно? Миграция БД всегда связана с выпуском новой версии приложения, и накатывается в момент запуска этой версии, внутри контейнера этой версии. Можно, конечно, вынести выполнение миграции в отдельный контейнер, но это имеет смысл только если у вас разные сервисы работают с общей БД, что плохо само по себе, и вызывает кривизну в других местах вроде этого.
- После миграций — стартуют тесты
- Если тесты успешные — должны стартануть контейнеры с приложением
Какие ужасы. Я тесты гоняю на CI. А когда идёт перезапуск приложения на prod/staging то там уже никаких тестов нет, контейнеры с приложением запускаются всегда.
Итого — обёрток ноль, всё делается банальным обновлением тега образа с нашим сервисом (собранного на CI после прохождения тестов) в yml-файле описывающем стек и запуском docker stack deploy. Миграции выполняет либо сам сервис при запуске, либо shell-скрипт запускающий сервис сначала выполняет команду, которая проверяет версию схемы БД и выполняет необходимые миграции, а потом запускает сервис — да, этот двухстрочный скрипт можно гордо назвать "обвязкой", нет, никаких проблем она не создаёт.
Я уж не говорю, если пришлось бы какой-либо контейнер запускать по таймеру (крон, да?)
Да, причём не контейнер по крону, а контейнер запущенный всегда, внутри него — обычный крон-сервис, который запускает что и когда нужно.
Да, причём не контейнер по крону, а контейнер запущенный всегда, внутри него — обычный крон-сервис, который запускает что и когда нужно.
Уже кривизна. Почему не воспользоваться кроном на хостовой машине?
Какие ужасы. Я тесты гоняю на CI. А когда идёт перезапуск приложения на prod/staging то там уже никаких тестов нет, контейнеры с приложением запускаются всегда.
К сожалению не весь пишем мы и не весь софт из мира поней и единорогов.
Ещё раз повторю вопрос — сложные зависимости пробовали реализовывать?
Ну, судя по ответам — нет.
Вопрос «нафига они нужны» — он за скоупом нашего разговора
Кстати, systemd с этим прекрасно справляется
Почему не воспользоваться кроном на хостовой машине?
Потому, что это крон-задачи конкретного проекта, которые вполне логично запускать способом, удобным разработчикам этого проекта, включая использование привычного им крон-демона, работающего в контексте и с правами этого проекта.
Кроме того, когда этот сервис мигрирует (или масштабируется) между серверами, то намного удобнее когда абсолютно всё его хозяйство, включая настройки крона, мигрируют штатным образом — а для этого они должны быть внутри контейнера этого проекта, а не в systemd сервера, на котором он когда-то в прошлом запускался.
Ещё раз повторю вопрос — сложные зависимости пробовали реализовывать?
Не такие, как Вы описываете. Когда я сталкиваюсь с таким, то я просто переделываю это нормально — моя задача решить проблему заказчика, а не механически выполнять идиотские требования "настроить накат миграций именно таким конкретным кривым способом". По сути, когда я попадаю на новый проект, то первое, что я там делаю — настраиваю нормально CI/CD, потому что писать код без этого я уже давно разучился.
моя задача решить проблему заказчика, а не механически выполнять идиотские требования «настроить накат миграций именно таким конкретным кривым способом».
повторюсь — речь не про миграции как таковые. Речь про то, что докер из коробки не умеет нормальные сложные зависимости между сервисами. Решается обвязками. Можно башем. Можно systemd. Можно вообще отдельный служебный контейнер, который будет имплементировать эту логику.
когда этот сервис мигрирует (или масштабируется) между серверами, то намного удобнее когда абсолютно всё его хозяйство, включая настройки крона, мигрируют штатным образом
Дискуссионный вопрос — сколько должно быть кронов и где они должны быть (запросто, что крон джоб должен быть в единственном экземпляре). Самое верное, имхо, мигрировать в куб.
Мы действительно используем докер на standalone хостах, потому что это удобно и круто.
В других проектах — куб.
Каждой задаче — свои инструменты.
По сути, когда я попадаю на новый проект, то первое, что я там делаю — настраиваю нормально CI/CD, потому что писать код без этого я уже давно разучился.
и как это релевантно к «докер из коробки не умеет нормальные сложные зависимости между сервисами»?
нормальные сложные зависимости
А Вы ещё не устали считать сложность — нормой? Я вот давно устал. Поэтому стараюсь делать всё как можно проще. Получается… ну, чаще получается, хотя и не всегда, к сожалению.
Когда используемый инструмент позволяет делать вещи сложно не испытывая от этого заметного дискомфорта — многие тут же радостно делают сложно… потому что для того, чтобы сделать просто — надо сначала хорошо подумать, а думать без острой необходимости многие избегают. Так что лично я предпочитаю использовать инструменты, которые не считают сложное нормой и не провоцируют делать сложно — они помогают мне находить более простые решения текущей задачи.
Конечно, возможностей простых инструментов иногда не хватает. Но я предпочитаю брать сложные не раньше, чем это произойдёт — и происходит это, на самом деле, не так уж часто.
и как это релевантно к «докер из коробки не умеет нормальные сложные зависимости между сервисами»?
Простите за вырванную из контекста цитату выше, она была нужна чтобы подготовить контекст для ответа на заданный вопрос.
Это релевантно потому, что взяв изначально более простые инструменты (runit вместо systemd, docker вместо k8s) я мотивирую себя решить задачу настройки CI/CD более простым способом, чтобы обойтись без многократно упомянутых портянок/костылей на баше. Что, в свою очередь, нередко приводит к необходимости сначала подчистить проект, как именно в нём делаются миграции, какие у него зависимости между сервисами, etc. — и, что характерно, такой подход пока что всегда шёл на пользу проекту.
я лично абсолютно уверен, что существование заговоров это факт, а не теория — это довольно очевидно
Голая вера и ничего больше. Вообще, конспирология это римейк веры в злобных демонов. Человеку проще не принимать во внимание, что другие люди могут мыслить иначе и не считать его идеи великим благом. Ему проще верить в тайных негодяев и вредителей.
скорость запуска системы — это самое главное
Может и не самое главное. Но когда в 2018 году система с многоядерным процесором и SSD грузится по 40 секунд это позорище.
бессмысленная фича
решил несуществующую проблему
Я тоже не понимаю, почему разработчики решают кучу всяких «несуществующих» проблем, ведь всем известно, что Linux существует исключительно для powerman и его задач XD
Но когда в 2018 году система с многоядерным процесором и SSD грузится по 40 секунд это позорище.
Откуда Вы взяли эту цифру? Я вот не поленился, и специально только что перегрузился несколько раз с секундомером. Мой Gentoo с runit загружается в "серверном" стиле (без X-oв и нужных только им сервисов) за 5.5 секунд. Если грузить в обычном режиме, как десктоп, то загрузка занимает примерно 40 секунд, но учтите, что сюда входят:
- 60 runit-сервисов (включая vpn, без которого упомянутые ниже браузер сотоварищи бы не запустились нормально)
- ручной ввод пароля
- запуск 20-ти терминалов, некоторые терминалы сразу с приложениями (mc, mutt, rtorrent, несколько ssh на сервера)
- pidgin, keepass, dropbox…
- и, самое главное — нескольких окон браузера с тучей вкладок в каждом
Таймер остановил глядя когда не просто все они полноценно отрисовались, но и нагрузка на CPU упала, т.е. даже браузер закончил грузиться.
Насколько лучше сделает то же самое systemd, и, самое главное, насколько это важно?
Действительно, они ведь съёмные, поэтому их постоянно втыкают в середине процесса загрузки… нет? Странно… а почему тогда об этом должна беспокоиться система загрузки?
Потому что бывают носители, которые только притворяются съёмными, но на самом деле являются системными.
Но с другой стороны удобно, что среда на облачных хостах и реальных серверах одинаковая. Не надо переучиваться…
P.s. про внешние накопители типа usb — это к ребятам выше, они про такие «съёмные» накопители говорили
Любители механики восстанавливают классические автомобили, любители ПО поддерживают классический init. У каждого своё хобби.
Банально нет ни одного пункта, по которому sysvinit может выиграть в надёжности и безопасности на современном сервере. Даже элементарный запуск сервиса на systemd написать проще чем через init.d, не говоря уже о контроле работы. Замена cron снимает множество проблем, а "дублированный функционал" легко отключается, если требуется более полное решение.
Упёртость отдельный коллег лишь показатель тупика, в который они себя загнали протестом.
На daemontools/runit/s6 запуск сервиса написать ещё проще. Вот вам примеры, и покажите, насколько проще выглядит вариант systemd:
- /etc/service/ssh/run:
#!/bin/sh exec /usr/sbin/sshd -D 2>&1 - /etc/service/nginx/run:
#!/bin/sh ulimit -n 8192 exec nginx -g 'daemon off;' - /etc/service/docker/run
#!/bin/sh exec dockerd 2>&1
И какие конкретно проблемы, точнее, множество проблем, снимает замена cron?
Хотя нет, не будем ждать милостей от природы, я сам добавлю пример "простого" сервиса на systemd — скажу честно, не выбирал, взял тупо первый, который гарантированно будет на сервере с убунтой:
- /etc/systemd/system/sshd.service:
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
Alias=sshd.serviceДобавьте всё, что делает этот Unit в ваш пример daemontools и без костылей не обойдётесь. По факту, нужны только ExecStart и WantedBy в соответствующих разделах. Лет 10 назад daemontools был незаменим, но сейчас systemd уже на голову выше.
systemd timer активирует сервис, который запускается по расписанию со всеми гарантиями и плюшками в виде cgroups, limits, namespaces и journal. В простом cron запускается команда, которую требуется дополнительно обезопасить хотя бы от двойного запуска — это самая частая проблема.
К слову, когда-то уже упоминал, что изначально тоже был противником systemd.
А зачем мне всё это? Нет, серьёзно, что такого делает демон ssh на ваших серверах, чего не делает на моих? Давайте я скажу, что он делает на моих: очень надёжно запускается, и, при необходимости (мной вручную, или автоматически после падения), не менее надёжно перезапускается. А всё остальное время — просто работает. И остальные сервисы на моих серверах под runit делают ровно то же самое: они всегда гарантированно запущены и просто работают. runit позволяет очень просто настраивать их запуск (примеры выше), удобно смотреть их текущее состояние, запускать/перезапускать/останавливать. Плюс, важная фишка, не менее надёжно, качественно, удобно и единообразно вести логи всех сервисов через svlogd — с фильтрацией, ротацией, etc. … и даже, Вы не поверите, в текстовом формате! :)
Я никогда не спорил с тем, что у systemd намного больше фич… я высказывал обоснованное сомнение в нужности и полезности этих фич, а так же в том, что они окупают недостатки systemd.
что нужно было бороться только со скриптом, а не с целой системой инициализации
С чем конкретно вам бороться нужно было? Вот минимально необходимый unit, чтобы сервис работал (причём, если не надо его запускать после ребута автоматом, то достаточно 2 первые строки):
[Service]
ExecStart=/bin/sleep 100
[Install]
WantedBy=multi-user.targetВы можете на shell'е написать менее чем в 4 строки скрипт для sysvinit?
Systemd вообще никаким образом не помогает от сдохших сервисов
Смотря как сдох. Если упал — будет перезапущен. А если процесс подвис, то это не для systemd задача. И кофе в постель он тоже не приносит.
фичи десктопных сред на систему инициализации
Какие конкретно?
не все авторы софта или ментейнеры дистров сами хорошо разбираются в systemd
Точно так же, как не разбирались в sysvinit скриптах. Вы их смотрели — там сплошная копипаста и костыли. Люди вообще не любят доки читать, зато транслировать чьи-то там слухи гораздо проще.
но пока его не поставишь, все работает и без него?
Так всё работает и с ним, в чём проблема? В том, что надо ещё десяток man'ов прочитать?
А если процесс подвис
Есть механизм и директива WatchdogSec=, единственное, что требуется от сервиса уметь периодически слать sd_notify со значением WATCHDOG=1. При этом sd_notify можно использовать из поставки либо прямо слать дейтаграммы на AF_UNIX сокет из переменной окружения $NOTIFY_SOCKET. Для скриптов есть консольная утилита systemd-notify.
Да, я именно так и написал
единственное, что требуется от сервиса, уметь периодически слать sd_notify
Придется накостылять скрипт или просить разработчиков сервиса добавить такую функциональность. Ведь по другому никак не узнать именно о зависании. Вообще systemd не запрещает писать скрипты и не думаю, что для фанов sysvinit это проблема. Тем более, если такая функциональность уже была в sysvinit скрипте, то останется добавить только одну строчку с вызовом systemd-notify
Скрипт не поможет, потому что отсылать должен $MAINPID, иначе будет так:
Dec 04 09:27:02 host systemd[1]: test-notify.service: Got notification message from PID 9274, but reception only permitted for main PID 9267А не логичней ли, если вам правда нужно чтобы сервис гарантировано жил, использовать таки полновесную систему мониторинга, а не штуку, которая иногда рестартит, иногда нет?
systemd реализует примерно аналогичные примитивы по мониторингу сервисов как и докер. И ничего — никто не жалуется. На самом деле, это правильный подход. Потому что то, что было раньше — с теми же PID-файлами — это тихий ужас. Я даже более того скажу — был у меня случай в практике, когда PID-файл сервиса был создан, в нем был записан PID. Сервис тихо сдох никого не уведомив, а другая приложуха этот PID захватила. Естественно, что после этого сервис было невозможно перезапустить штатно ))))
Проблема в том, что завязывать целые пользовательские среды на systemd это странно, потому что помимо линукса есть есть *bsd, солярка, и все тот же линукс, но без systemd.
проблема в том, что в КАЖДОЙ системе свой вариант системы инициализации. Буквально где-то в соседних комментах об этом говорилось.
Нее, /bin/sleep 100 писать в rc.* нельзя. Как минимум, должно быть /bin/sleep 100 &. А еще нужно проверить первый аргумент, который может быть одним из вот этого списка: start, stop, restart, status, poll, enabled, rcvar...
Более того, systemd — единственный из всех инициализаторов, который может при завершении (stop) гарантировано прибить всё, что нафоркал демон. Ни upstart, ни sysv-init физически не имеют возможности трекать потомков.
Я не знаю что это было — баг в openvpn, баг в конкретной версии systemd или мои кривые руки
Слишком мало информации для анализа. :)
падал без воскрешения, хотя иногда systemd его таки перезапускал
Потому что «проверенную временем» схему с форком и уходом в background надо безжалостно выпиливать везде где только можно. В случае с openvpn это опция daemon (её найти и удалить).
В вашем случае, скорее всего, openvpn форкался и в таком случае systemd может и не отследить, что сервис упал.
Кстати, у меня под убунтой тоже пару раз openvpn пришлось руками перезапускать. Сейчас глянул:
# grep daemon /lib/systemd/system/openvpn@.service
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pidИ вот вопрос, почему же штатный пакет openvpn убунты годами распространяется с таким конфигом под systemd, который не в состоянии обеспечить стабильный перезапуск сервиса?
Я бы предположил, что дело в том, что systemd очень богат ненужными фичами — тот же runit поддерживает только сервисы, которые не отцепляются от родителя, поэтому под ним openvpn с --daemon никому даже не приходит в голову запускать, ведь это тупо не сработает.
В результате мы имеем факт: под runit openvpn перезапускается гарантированно, а под systemd — нет. И чья это вина, systemd или разработчиков пакета openvpn — как минимум не очевидно.
распространяется с таким конфигом под systemd, который не в состоянии обеспечить стабильный перезапуск сервиса
Маинтейнеры тоже, бывает, не любят документацию читать. Вообще, это копипаста из дебиана (там тоже --daemon). По хорошему, надо бы баг зарепортить, конечно.
systemd очень богат ненужными фичами
Это сделано для совместимости, чтобы systemd-sysv-generator(8) нормально работал, потому что в случае с sysv init нормальное поведение — это форкающийся демон. Подозреваю, что в будущем эту штуку удалят.
runit поддерживает только сервисы
runit никогда не заявлял совместимость с sysv init, равно как не претендовал на его полную замену (хотя в радикальной конфигурации его вроде даже можно как init запускать, размуеется, переписав вначале все скрипты запуска сервисов).
И чья это вина
Ничья. Если бы openvpn упал в системе с sysv init его бы никто даже не пытался бы перезапустить.
его вроде даже можно как init запускать
Можно, у меня так везде. Скрипт запуска меньше 300 строк, очень просто, наглядно и удобно. Кстати, я лет 10 назад об этом тут писал (https://habr.com/post/21205/), и с тех пор ничего не изменилось — по-прежнему очень удобно, поддержка этих скриптов занимает примерно пол часа раз в 3 года, используются на кучке домашних машин и кучке серверов, работают как часы.
Люди вообще отвыкли от простых решений, добавляют accidental complexity в диких количествах везде, куда дотянутся. Вы давно работали с системой, у которой абсолютно весь код выполняемый при загрузке, запуске каждого сервиса, и выключении системы занимал 400 (на сервере) или 611 (на десктопе) строк на bash? Подозреваю, что вообще никогда. А для меня это — норма. Я хочу иметь возможность за пол часа-час прочитать и понять всё, что при этом происходит, чтобы иметь возможность легко сопровождать систему.
Если бы openvpn упал в системе с sysv init
Я вот не очень понимаю, с кем Вы сейчас разговаривали. Я разве хоть слово про sysvinit в комментариях к этой статье сказал? sysvinit это кошмар, безусловно, но systemd это тоже кошмар, просто совершенно по другим причинам. Давайте сравнивать systemd с нормальными альтернативами, вроде runit/s6.
Посмотрел, там такое:
Type=notify
Restart=on-failure
Если вышло успешно, то перезапускать не будет. Если неуспешно — перезапустит. Чтобы перезапускало всегда — Restart=always.
А если там on-failure, а openvpn вышел с кодом 0, то какие к systemd придирки?
on-failure. И это не придирки к systemd, это констатация факта, что и у меня и у PerlPower openvpn падал и не перезапускался под systemd, причём неоднократно. Возможно, это баг openvpn — я же не знаю, по какой причине он в те моменты завершался с кодом 0, я его об этом не просил. Возможно, это в пакете плохо написали unit-файл. Мне разве должно быть до этого дело? Под runit это не происходит, под systemd — случается, причём в конфигурации по умолчанию. Я не спорю, что под systemd можно всё настроить надёжно — я говорю, что под ним очень просто настроить не надёжно, что и происходит на практике.
— А вот мой сосед взял дрель SystemD и не закрутил патрон, и там сверло не крутится.
— Там на патроне есть полоска для того, чтобы закрутить, поверни её.
— Какое мне до этого дело? У дрели RunIT, которую я взял у другого соседа патрон уже со сверлом и всё работает. Я не спорю, что у SystemD дрели можно закрутить патрон — я говорю, что там очень просто получить от соседа дрель с незакрученным патроном, что и происходит на практике.
Лучше провести аналогию с языками со статической и динамической типизацией. У обоих хватает сторонников, но считается, что первые заметно усложняют процесс выстрела себе в ногу. Я 18 лет писал на Perl и не могу сказать, что сильно страдал от отсутствия типов, хотя изредка, не смотря на все старания писать чистый код, это приводило к багам. Сейчас пишу на Go и не могу сказать, что я стал фанатом статической типизации… тем не менее, очевидно, что написать некорректный код на Go заметно сложнее, чем на Perl, и такой код будет намного сильнее "бросаться в глаза".
Здесь ситуация похожая: run-скрипт на runit, который останавливает сервис если он завершился с кодом 0 — это большая редкость плюс ручная обвязка на шелле, такое сильно заметно, и по ошибке такое не напишешь. В случае же systemd — нифига эти нюансы не заметны, и, как мы видим, по ошибке или нет, но такое делают.
Я не против сложных и навороченных приложений. Любимые мной vim и mutt явно попадают в эту категорию, как и zsh. Но я не хочу видеть такую гибкость и сложность в приложении, отвечающем за загрузку системы и стабильность работы всех сервисов — в этом случае мне намного важнее её очевидность и надёжность.
Блин, это не нюансы а конкретная фича. Её кто-то руками написал. Взял и написал Restart=on-failure. Это как я бы в статически типизированном языке Rust написал бы unsafe{ всякая пакость} а потом бы заявлял, что язык позволяет делать всякую пакость если я написал unsafe. Я не понимаю каким образом неочевидным является поведение Restart=on-failure vs Restart=always. Более того, это написал мейнтейнер openvpn, а не попросили написать пользователя, так что это баг чистой воды.
Я совершенно не понимаю вашей аргументации. runit не является init'ом, а сравнивая сложность написания юнитов для systemd с написанием, кхем, init.d скриптов (которых я в своей жизни наотлаживался больше, чем хочется), я могу сказать, что systemd — это мёд, да ещё и ложкой.
Это реально инструмент, который берёт на себя всю грязную работу и все нюансы и выдаёт наружу чёткий интерфейс в обмен на декларативный конфиг.
runit не является init'ом
Вообще-то, является.
# qlist sys-process/runit | grep bin/
/bin/runsv
/bin/runsvdir
/bin/chpst
/bin/runsvchdir
/bin/sv
/bin/svlogd
/sbin/runsvdir-start
/sbin/runit-init <--- это оно
/sbin/runit
/sbin/utmpsetс написанием, кхем, init.d скриптов
Вот. Опять. Я ничего не говорил про sysvinit и init.d скрипты. Я не хочу сравнивать sysvinit и systemd, я не хочу выбирать между ними двумя, категорически! Потому что да, я могу выбрать systemd. Не уверен, потому что очень уж меня раздражает systemd, но не исключаю, что выберу именно его. Потому что init.d — это просто за гранью добра и зла. Но я выбираю runit/s6, потому что они намного лучше и одного и второго, это просто золотая середина, не настолько навороченные как systemd, и не настолько ненадёжные как init.d скрипты.
Во-вторых, вроде systemd никак философии юникс не противоречит, это множество маленьких демонов взаимодействующих между собой через единый интерфейс, детали отличаются, но суть вроде та же, я глубоко не копал, поправьте если ошибаюсь.
В-третьих, бинарность логов это никакая не проблема, а фича, которая даёт многое, например возможность индексирования, какая вам разница как храниться лог? В текст он легко превращается. Те же рассуждения и о бинарности протокола.
Ну и переход от написания скриптов к конфигам (unit файлам), это просто шаг в будущее, в первую очередь по причине безопасности, ну и читаемость выше за счёт унификации формата.
Теперь о том, что якобы «в системд есть свой нтп, свой журнал, свой крон и так далее». А ТЫ НЕ ИСПОЛЬЗУЙ! systemd сугубо модульный и ты можешь не использовать модули, которые тебе не нравятся, вот просто не использовать и все, а использовать прежний инструмент.
Ну а теперь мнение *nix-админа со стажем администрирования больше 20 лет(то есть мой стаж больше, чем возраст любого диванного systemd-хейтера в мире): systemd — лучшее что случалось с Linux-based OS за последние 20 лет. Вот просто лучшее. Это и прекрасные юнит-файлы, вместо портянок на шелле, это и зависимости при старте, это и ЕДИНЫЙ инструмент во всех основных дистрибах(раньше ты заходил и начинал вспоминать где тут надо сказать /etc/init.d/bla-bla restart, где service bla-bla restart, где restart bla-bla, а где еще какую-то фигню, теперь ты знаешь, что есть systemctl и пофигу это Debian/Ubuntu, это RHEL/CentOS или еще какой маргинальный SLES).
Минусы в том, что помимо systemd unit'ов иногда удобно хранить настройки в дефолтных файлах конфигов. Ну, и некоторые юниты от разработчиков сервисов ущербные. Взять ту же монгу. Выглядит очень мерзко, когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл. Решение? Общего не нашел, но можно делать свой юнит и класть его рядом со «штатным». Главное — потом не забыть, что там админ/разработчик понаписал.
Ну, и некоторые юниты от разработчиков сервисов ущербные.
Ну да, например в mongod.service указано Type=forking, однако надо при первой же возможности от форка избавляться. Монга сама умеет в foreground стартовать.
когда какая-то монга при обновлении или переустановки переписывает твой собственноручно поправленный юнит файл.
А вы, надеюсь, правите не в /lib/systemd/system? Надо это делать в /etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.
Решение? Общего не нашел,
Например, systemctl mask some.service и делаем свой unit с немного другим именем.
А вы, надеюсь, правите не в /lib/systemd/system? Надо это делать в /etc/systemd/system, а пакетам, в свою очередь, туда лезть не нужно.
Спасибо за напоминание, Но вообще вопросы раскладки чего-либо по файловой системе всегда были дискуссионными. Тем более, когда используешь несколько разных дистрибов (ub/deb vs rhel/centos)
Как монга в таких условиях может переписать исправленный файл? Это точно минус systemd?
Как правильно отметили ниже юниты из пакета должны идти в /lib/systemd/system, а твои личные в /etc/systemd/system и те которые из /etc/systemd/system при наличии одноименных в /lib/systemd/system имеют приоритет. Так что выход складывать свои на место, куда положено. А если мэйнтейнер складывает свои не туда, то бить ему по рукам.
systemctl edit mongo и редактируйте до посинения. При этом всё будет обновляться с сохранением изменений и бла-бла-бла.
Леннарт Поттеринг может быть хорошим программистомВ каком месте он хороший программист, если он даже философию сообщества не осилил?
А вот всё остальное — включая команду service и т.д. — это уже система инициализации, написанная на баше. Я бы сказал, что в этом месте её надо закапывать, но нет, на баше написана не только система, но и её файлы конфигурации. /etc/rc.d/foo — это не конфиг, это скрипт. Который при этом конфиг. Но тьюринг-полный. Мы все любим тьюринг-полные файлы конфигурации на bash.
Debian и Devuan объединили усилия ради sysvinit