Комментарии 58
systemd хорошо и годно, но почему легаси разломали? допустим, есть у меня старые скрипты, где есть /etc/init.d/blabla start.
что мешает systemd научиться обрабатывать симлинки из /etc/init.d/? или быть может уже есть правильный путь для этого? те же upstart или runit симлинки полностью поддерживают.
что мешает systemd научиться обрабатывать симлинки из /etc/init.d/? или быть может уже есть правильный путь для этого? те же upstart или runit симлинки полностью поддерживают.
Может чтобы ускорить миграцию на systemd? Про хорошо и годно вопрос не однозначный. Я вот с грустью смотрю на список дистрибутивов без systemd и размышляю куда мигрировать.
Gentoo — OpenRC просто шикарен и, к счастью, systemd там не светит.
Что значит «не светит»? О_о
В Gentoo он, SystemD, как и многие другие «альтернативы», как всегда, «на выбор». Если пользователь хочет — он может сам его поставить и настроить. Раньше ещё был eselect init, но, что-то, забили на него и выпилили :) Всё равно ядру «лучше» по совету апстрима не симлинк указывать, а путь до реального бинарника :)
В Gentoo он, SystemD, как и многие другие «альтернативы», как всегда, «на выбор». Если пользователь хочет — он может сам его поставить и настроить. Раньше ещё был eselect init, но, что-то, забили на него и выпилили :) Всё равно ядру «лучше» по совету апстрима не симлинк указывать, а путь до реального бинарника :)
Почему systemd это плохо?
Да, я понимаю, что systemd не соответствует linux(unix?) философии, но ведь это шикарная вещь!
cc kt97679
Да, я понимаю, что systemd не соответствует linux(unix?) философии, но ведь это шикарная вещь!
cc kt97679
Я далек от того, чтобы утверждать, что systemd это плохо. Давайте проведем аналогию с автомобилями. Машину выпуска 80-х годов прошлого века можно починить в гараже своими силами. Машину выпуска 2010-го года в гараже починить не реально. Это не хорошо и не плохо, это то, куда пришло автопроизводство исходя из рыночной коньюктуры. Если бы люди покупали только машины, которые можно ремонтировать в гараже, то ситуация была бы другая. Но люди охотно покупают машины, которые можно ремонтировать исключительно методом агрегатной замены и исключительно у дилера. Что касается systemd то тут похожая ситуация с той разницей, что возможность ремонта в гараже для многих критична. systemd достаточно новая штука. Им предполагается заменить ключевые компоненты системы, обкатанные годами. Негативный опыт использования systemd, в том числе моими непосредственными коллегами, уже есть. Мне очень не комфортно использовать в продакшене систему, которую я не могу починить отредактировав пару скпиптов. А в том, что она не будет ломаться, у меня пока что уверенности нет. Вот такая моя личная позиция, которую я ни в коем случае никому не навязываю.
Машину выпуска 2010-го года в гараже починить не реально.
Всё реально. Было бы желание и гараж ))
Ничего существенно нового в новых машинах нет. Чуть больше электроники, чуть больше датчиков, но по сути движок тот же. Всё дело в наличии документации (которую можно найти в интернете) и инструментов.
Вот только когда после замены какой-нить фигни, машина не заводится, потому что электроника кричит «сбросьте датчик специальным лицензированным ПО от официального сервис центра», начинаешь понимать, что в такой «гараж» следует вложить столько, что проще уже в сервис центр.
НЛО прилетело и опубликовало эту надпись здесь
> «Это сбоку и специально так сделано.»
Но машина тем не менее не заведется, если я просто куплю запчасть и сам ее в гараже поменяю. Мне нужно будет и программатор завести и разобраться со всеми этими датчиками, то есть кроме замены запчасти, что можно сделать чисто интуитивным путем, если руки из нужного места растут, необходима процедура, которая не интуитивна, и отверткой не решается.
P.S. Кстати почему это не необходимость рынка? Как раз для развития официальных сервисов и сделано. Как чипованные картриджи.
Но машина тем не менее не заведется, если я просто куплю запчасть и сам ее в гараже поменяю. Мне нужно будет и программатор завести и разобраться со всеми этими датчиками, то есть кроме замены запчасти, что можно сделать чисто интуитивным путем, если руки из нужного места растут, необходима процедура, которая не интуитивна, и отверткой не решается.
P.S. Кстати почему это не необходимость рынка? Как раз для развития официальных сервисов и сделано. Как чипованные картриджи.
Я же выше написал:
>> Было бы желание
>> Всё дело в наличии документации (которую можно найти в интернете) и инструментов
Сейчас все машины свежие выпускаются с единой цифровой шиной, через которую и диагностику проводят и ошибки сбрасывают. И софт на спецфорумах можно накопать и переходники для подключения к ПК найти.
Ну а на крайний случай для сброса ошибки можно и в сервис отвезти. Сброс ошибки будет стоить гораздо меньше чем работы по замене узлов, сами узлы у диллеров и т.п.
Пока машина на гарантии я в неё не лезу — диллер пусть делает, а вот когда гарантия закончится, при надобности буду разбираться. Предыдущую машину ремонтировал вплоть до перебора и замены движка, так что опыт есть.
>> Было бы желание
>> Всё дело в наличии документации (которую можно найти в интернете) и инструментов
Сейчас все машины свежие выпускаются с единой цифровой шиной, через которую и диагностику проводят и ошибки сбрасывают. И софт на спецфорумах можно накопать и переходники для подключения к ПК найти.
Ну а на крайний случай для сброса ошибки можно и в сервис отвезти. Сброс ошибки будет стоить гораздо меньше чем работы по замене узлов, сами узлы у диллеров и т.п.
Пока машина на гарантии я в неё не лезу — диллер пусть делает, а вот когда гарантия закончится, при надобности буду разбираться. Предыдущую машину ремонтировал вплоть до перебора и замены движка, так что опыт есть.
Я вот не понимаю людей, которые вопят как потерпевшие о том, что systemd, типа, не соответствует unix-философии потому, что, панимаэш, в одном пакеты живут десятки самых разнообразных утилит, которые работают только друг с другом.
Люди, вы вообще когда-нибудь видели исходники UNIX? Нет? Сходите, полюбуйтесь.
Каждая версия содержит в одном «пакете» десятки утилит, которые рассчитаны на совместную работу и которые нигде, кроме как в соответствующей системе, не собираются и в комплекте с «чужими» утилитами не работают — точь-в-точь как в systemd.
Или у нас теперь уже сам UNIX перестал соответствовать философии UNIX??? Оксюморон же!
Другое дело, что кой-какие вещи, может быть, засунуты зря в основной демон systemd, но там зачастую оказывается что выделить что-то в отдельную утилиту — себе дороже: будет больше кода, общающегося с утилитой, чем кода, который реализуется нужный функционал напрямую. А так… systemd — это как раз скорее попытка «вернуться к истокам»…
Люди, вы вообще когда-нибудь видели исходники UNIX? Нет? Сходите, полюбуйтесь.
Каждая версия содержит в одном «пакете» десятки утилит, которые рассчитаны на совместную работу и которые нигде, кроме как в соответствующей системе, не собираются и в комплекте с «чужими» утилитами не работают — точь-в-точь как в systemd.
Или у нас теперь уже сам UNIX перестал соответствовать философии UNIX??? Оксюморон же!
Другое дело, что кой-какие вещи, может быть, засунуты зря в основной демон systemd, но там зачастую оказывается что выделить что-то в отдельную утилиту — себе дороже: будет больше кода, общающегося с утилитой, чем кода, который реализуется нужный функционал напрямую. А так… systemd — это как раз скорее попытка «вернуться к истокам»…
НЛО прилетело и опубликовало эту надпись здесь
У меня любые несовместимости вызывают желание выпилить системд. Если честно, я вообще не понимаю, зачем он нужен. У меня Sys V отлично работает.
Давно ли вы писали init-скрипты?
бывает иногда. Вообще, есть же генератор инит-скриптов.
Поделитесь, то куча народу мучается.
Кстати, сколько major версий основных массовых дистрибутивов (Debian, RHEL, Ubuntu, SLES) поддерживает? Upstart-скрипты генерирует? Таблицы имён сервисов и базовых зависимостей за пределами LSB, от которых может зависеть конкретный инит-скрипт имеет?
Кстати, сколько major версий основных массовых дистрибутивов (Debian, RHEL, Ubuntu, SLES) поддерживает? Upstart-скрипты генерирует? Таблицы имён сервисов и базовых зависимостей за пределами LSB, от которых может зависеть конкретный инит-скрипт имеет?
metainit
> Кстати, сколько major версий основных массовых дистрибутивов (Debian, RHEL, Ubuntu, SLES) поддерживает?
Понятия не имею. Пользуюсь только дебианом
> Upstart-скрипты генерирует?
Не пользуюсь, не знаю.
> Таблицы имён сервисов и базовых зависимостей за пределами LSB, от которых может зависеть конкретный инит-скрипт имеет?
Не интересовался. Необходимые зависимости можно руками дописать.
Вообще, задача написания инит-скриптов столь редко возникает, что мне непонятны все эти сложности. Хотя, это только на дебиане так, наверное. Во всяких рхелах 90% софта приходится руками собирать, т.к. нет в дистрибутиве.
> Кстати, сколько major версий основных массовых дистрибутивов (Debian, RHEL, Ubuntu, SLES) поддерживает?
Понятия не имею. Пользуюсь только дебианом
> Upstart-скрипты генерирует?
Не пользуюсь, не знаю.
> Таблицы имён сервисов и базовых зависимостей за пределами LSB, от которых может зависеть конкретный инит-скрипт имеет?
Не интересовался. Необходимые зависимости можно руками дописать.
Вообще, задача написания инит-скриптов столь редко возникает, что мне непонятны все эти сложности. Хотя, это только на дебиане так, наверное. Во всяких рхелах 90% софта приходится руками собирать, т.к. нет в дистрибутиве.
metainitdebian-specific, только для простых скриптов. Этакий boilerplate-generator, почти не снижающий затраты на поддержку в простых случаях и повышающий их в чуть более сложных.
Вообще, задача написания инит-скриптов столь редко возникает, что мне непонятны все эти сложности. Хотя, это только на дебиане так, наверное.Если вы:
— пишите свой софт,
— имеете нетривиальную конфигурацию софта из дистрибутива (например, несколько копий исходного сервиса),
— используете сторонний коммерческий софт, для которого не озаботились написанием нормального инит-скрипта,
то их писать приходится.
Во всяких рхелах 90% софта приходится руками собирать, т.к. нет в дистрибутиве.Не знаю, откуда вы взяли такую статистику, учитывая, что rhel/centos не пользуетесь. У меня возникает потребность в инит-скриптах для софта, которого нет ни в репозиториях centos, ни в debian.
может ли systemd работать с конфигами, сгенерированными на лету и находяшимися в произвольных директориях?
Да. Можно импортировать файл с парами ключ-значение (которые обычно хранятся в /etc/sysconfig/ или /etc/default/) в environment, можно запускать любые скрипты перед запуском, после запуска, после остановки (ExecStartPre, ExecStartPost, ExecStopPost) для генерации чего угодно.
Прошу прощения, надо было сформулировать более развернутый вопрос. Могу ли я при помощи systemd организовать мета сервис, который бы при запуске генерировал конфиги для компонент и запускал бы их, перезапускал компоненты в случае их аварийного завершения, при остановке мета сервиса останавливал бы запущенные компоненты и удалял бы сгенерированные конфиги? Я хочу зарегистрировать в systemd только метасервис, работа с компонентами должна происходить автоматически без человеческого вмешательства. Что произойдет, если при запущенном метасервисе машина внезапно уйдет на перезагрузку? При следующем старте компоненты будут запущены даже если метасервис запускается в ручном режиме? Отдельный вопрос: может ли systemd проверять живость сервиса при помощи сетевого запроса?
Всё равно не очень ясно чего вы хотите. Зачем вам какой-то загадочный метасервис если вы можете просто положить конфиги в
Сформулируйте задачу — и её можно будет обсуждать. Потому что пока что её формулировка слишком близка к «пойди туда, не знаю куда, принеси то, не знаю что».
/run/systemd/system? Тогда systemd их подхватит. Или, может, вы хотите себе завести «дочерний» systemd? Запустите его с опцией --user и не забудьте установить переменные XDG_*. Если вам нужна какая-то хитрая логика по проверке живости сервера, то вам придётся создать отдельный процесс, который будет периодически сообщать systemd о том, что ваш сервис ещё жив.Сформулируйте задачу — и её можно будет обсуждать. Потому что пока что её формулировка слишком близка к «пойди туда, не знаю куда, принеси то, не знаю что».
Я хочу понять можно ли перевести на systemd вот это: github.com/hulu/statsd-router/blob/master/example/init.d.sh. И что я при этом выиграю.
От простого перевода одного скрипта — скорее всего ничего не выиграете. Просто один набор костылей заменится на другой. Нужно более аккуратно смотреть на архитектуру statsd и его потребности.
Хотя я на тему использования systemd для управления демонами в кластере как-то вообще не думал, не знаю можно ли от него получить вообще хоть какую-то пользу в таком раскладе. Всё-таки он больше для управления локальными процессами.
Хотя я на тему использования systemd для управления демонами в кластере как-то вообще не думал, не знаю можно ли от него получить вообще хоть какую-то пользу в таком раскладе. Всё-таки он больше для управления локальными процессами.
Вы можете спокойно генерировать новые unit'ы в /run/systemd/system/. Они будут видны systemd автоматически, без systemctl daemon-reload. Кроме того, эти конфиги автоматически удалятся при перезагрузке сервера.
Каждому сгенерированному «компоненту» можно указать политику перезапуска (параметр Restart, см man 5 systemd.service), но мониторинг сервиса (кроме стандартных механизмов — sigchld, pid file, dbus) — внешняя относительно systemd задача.
Также вам стоит разобраться с тем, какие части от каких будут зависеть. У systemd очень развитая система зависимостей (Requires, Wants, BindTo, PartOf и ещё некоторые, см man 5 systemd.unit).
Каждому сгенерированному «компоненту» можно указать политику перезапуска (параметр Restart, см man 5 systemd.service), но мониторинг сервиса (кроме стандартных механизмов — sigchld, pid file, dbus) — внешняя относительно systemd задача.
Также вам стоит разобраться с тем, какие части от каких будут зависеть. У systemd очень развитая система зависимостей (Requires, Wants, BindTo, PartOf и ещё некоторые, см man 5 systemd.unit).
Потому что в каждом дистрибутиве был свой велосипед из этих init скриптов. И если есть скрипт для debian, то для того чтобы запустить его в suse надо было прыгать с бубном.
Чисто для справки: System V init Scripts systemd полностью поддерживает. По крайней мере в RHEL7:
Если же у вас нормальные скрипты, то с ними на в RHEL7, ни в CentOSе ничего случиться не должно.
Although not encouraged, System V init scripts are still supported. There are still some services in RHEL 7 that are implemented in System V init scripts.Тут скорее проблема в другом: во многих случаях эти самые скрипты написаны через одно место, неправильно описывают зависимости от других компонент и работают, в общем-то, по чистой случайности.
Если же у вас нормальные скрипты, то с ними на в RHEL7, ни в CentOSе ничего случиться не должно.
Вопрос не об этом. Еще раз объясняю. ivlis это тоже касается.
В дебиане/убунте когда обычный систем-файв инитскрипт заменялся на апстарт-джоб, файл /etc/init.d/servicename заменялся на симлинк на исполняемый файл upstart, например:
То же самое если я хочу использовать runit вместо init.
Cоответственно, я и какие-то древние скрипты можем вызвать /etc/init.d/rsyslog start и запустится rsyslogd.
теперь понятно, о чем речь?
В дебиане/убунте когда обычный систем-файв инитскрипт заменялся на апстарт-джоб, файл /etc/init.d/servicename заменялся на симлинк на исполняемый файл upstart, например:
lrwxrwxrwx 1 root root 21 окт. 2 2014 rsyslog -> /lib/init/upstart-job
root@hostname:/# /etc/init.d/rsyslog status Rather than invoking init scripts through /etc/init.d, use the service(8) utility, e.g. service rsyslog status Since the script you are attempting to invoke has been converted to an Upstart job, you may also use the status(8) utility, e.g. status rsyslog rsyslog start/running, process 5119
То же самое если я хочу использовать runit вместо init.
lrwxrwxrwx 1 root root 11 апр. 15 20:55 /etc/init.d/xupnpd -> /usr/bin/sv
root@hostname:/# /etc/init.d/xupnpd status run: xupnpd: (pid 10356) 963840s; run: log: (pid 6347) 1532294s
Cоответственно, я и какие-то древние скрипты можем вызвать /etc/init.d/rsyslog start и запустится rsyslogd.
теперь понятно, о чем речь?
В Ubuntu 15.04 уже переползли на systemd, но привычные service webserver start (мой пользовательский сервис из /etc/init.d) всё ещё работают нормально.
Чем не тоже самое?
www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf
www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf
Серьёзное замечание по поводу OOMScoreAdjust=-1000.
Это ОЧЕНЬ серьёзно. Это настолько серьёзно, что утверждение следует читать так:
убейте пожалуйста всё, включая базу данных, getty, udev, ssh, но не убийвайте мой сервис. Заметим, если в системе всё настолько плохо, то следующим умрёт и этот сервис.
И нафига нам такой сервер в продакшене? Может, лучше, мирно сковырнуться по oom'у и перезапуститься?
OOMScoreAdjust надо делать в пределах нескольких сотен (меньше 500), иначе можно получить «странно залипший сервер». И, вообще, если это не системный сервис крайне высокой важности (ssh, udev), то разработчику лучше не трогать этот параметр, оставляят такие вещи на усмотрение системного администратора. Что для одного бизнес-критикал — для другого побрякушка.
Это ОЧЕНЬ серьёзно. Это настолько серьёзно, что утверждение следует читать так:
убейте пожалуйста всё, включая базу данных, getty, udev, ssh, но не убийвайте мой сервис. Заметим, если в системе всё настолько плохо, то следующим умрёт и этот сервис.
И нафига нам такой сервер в продакшене? Может, лучше, мирно сковырнуться по oom'у и перезапуститься?
OOMScoreAdjust надо делать в пределах нескольких сотен (меньше 500), иначе можно получить «странно залипший сервер». И, вообще, если это не системный сервис крайне высокой важности (ssh, udev), то разработчику лучше не трогать этот параметр, оставляят такие вещи на усмотрение системного администратора. Что для одного бизнес-критикал — для другого побрякушка.
Ещё полезная опция
Позволяет в вашем приложении-сервисе сделать начальную инициализацию, которая необходима перед продолжением загрузки системы, а потом вызвать из сервиса
и загрузка пойдёт дальше вместе с вашим работающим сервисом.
[Service]
Type=notify
Позволяет в вашем приложении-сервисе сделать начальную инициализацию, которая необходима перед продолжением загрузки системы, а потом вызвать из сервиса
sd_notify(0, "READY=1");
и загрузка пойдёт дальше вместе с вашим работающим сервисом.
Скажите мне главное: зачем нужен системд?
> разложены в трех каталогах: /usr/lib/systemd/system/
Гребанные хипстеры!
Я монтирую /usr в readonly (за исключением момента установки софта или апгрейда), а они туда изменяемые конфигурации выносят!
Гребанные хипстеры!
Я монтирую /usr в readonly (за исключением момента установки софта или апгрейда), а они туда изменяемые конфигурации выносят!
В /usr/lib/systemd/system лежат как раз неизменяемые файлы конфигурации, поставляемые с дистрибутивом. Если вы хотите что-то изменить, то вы должны скопировать файл в
Этот подход задолго до systemd появился. Никогда не обращали внимание, скажем, на файлик
/etc/systemd/system и изменить его уже там.Этот подход задолго до systemd появился. Никогда не обращали внимание, скажем, на файлик
/lib/init/fstab? А он таки там есть… по крайней мере на Ubuntu 14.04, где systemd ещё и не пахнет.Что происходит, когда ты желаешь отключить автостарт сервиса «из коробки»?
systemctl disable <name>
При вызове systemctl disable some-service.service удаляется симлинк из /etc/systemd/system/multi-user.target.wants/some-service.service (указывающий на файл /etc/systemd/system/some-service.service или /usr/lib/systemd/system/some-service.service, если первый не существует).
Из какой директории удалять определяется target'ом в котором этот сервис требовался. systemctl enable работает аналогично — создаёт симлинк.
Из какой директории удалять определяется target'ом в котором этот сервис требовался. systemctl enable работает аналогично — создаёт симлинк.
systemctl mask <name>
Я спросил «что происходит» а не «что нужно выполнить».
Создаеся симлинк /etc/systemd/system/<vendor.service> который указывает на /dev/null.
Именно такое сообщение выводится на английском языке, из команды за которую кто-то поставил минус.
Именно такое сообщение выводится на английском языке, из команды за которую кто-то поставил минус.
И это же написано в man systemctl:
mask NAME...
Mask one or more unit files, as specified on the command line. This will link these units to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits
all kinds of activation of the unit, including enablement and manual activation. Use this option with care. This honors the --runtime option to only mask temporarily until the next reboot of the
system. The --now option can be used to ensure that the units are also stopped.И да, cannot open `/lib/init/fstab' (No such file or directory)
Если вы хотите что-то изменить, то вы должны скопировать файл в /etc/systemd/system и изменить его уже там.Или использовать drop-in в /etc/systemd/system/service-name.service.d/some-conf.conf
А подскажите мне пожалуйста: есть у меня самописный юнит, который просто дёргает bash скрипт. Всё работает, но при запуске не возвращает консоль. Что не так?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Systemd за пять минут