Плохое и кошмарное
systemd-escape
Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.
На практике команда используется примерно так:
/bin/bash -c 'while true; do /usr/bin/etcdctl set my-container "{\"host\": \"1\", \"port\": $(/usr/bin/docker port my-container 5000 | cut -d":" -f2)}" --ttl 60; sleep 45; done'Если честно, это вообще выглядит как плохая идея в целом, но иногда, если вы пишете cloud-init для CoreOS, то это ваш лучший вариант. Escape-символы для новой строки я добавил для лучшей читаемости.
Если нам нужно создать команду
ExecStart с таким содержимым, то systemd не сможет распознать кавычки, потому что там он не работает в шелле. Поэтому команда, которая нормально запускается у вас в шелле, не будет работать как юнит systemd. Самым простым решением для systemd было бы реализовать нечто вроде shlex в Python или Shellwords в Ruby, но вместо этого была сделана заплатка словно из потустороннего мира, systemd-escape:$ man systemd-escape | head
SYSTEMD-ESCAPE(1) systemd-escape SYSTEMD-ESCAPE(1)
NAME
systemd-escape - Escape strings for usage in system unit names
SYNOPSIS
systemd-escape [OPTIONS...] [STRING...]
DESCRIPTION
systemd-escape may be used to escape strings for inclusion in systemd unit names.Конвертируем скрипт вверху в нечто приемлемое для SystemD:
$ systemd-escape 'while true;do /usr/bin/etcdctl set my-container "{\"host\": \"1\", \"port\": $(/usr/bin/docker port my-container 5000 | cut -d":" -f2)}" --ttl 60;sleep 45;done'
while\x20true\x3bdo\x20-usr-bin-etcdctl\x20set\x20my\x2dcontainer\x20\x22\x7b\x5c\x22host\x5c\x22:\x20\x5c\x221\x5c\x22\x2c\x20\x5c\x22port\x5c\x22:\x20\x24\x28-usr-bin-docker\x20port\x20my\x2dcontainer\x205000\x20\x7c\x20cut\x20\x2dd\x22:\x22\x20\x2df2\x29\x7d\x22\x20\x2d\x2dttl\x2060\x3bsleep\x2045\x3bdone
Согласитесь, что если вам необходимо для работы юнита внедрять цикл while из Bash, то вы уже в плохом положении, но иногда это требуется для шаблонов.
Бинарные логи
Если вы не в курсе, journald хранит свои логи в бинарном формате. Это ломает привычные инструменты, которые мы привыкли использовать для мониторинга системы:
tail, cat, less и grep становятся бесполезны. С бинарным форматом возможно и повреждение логов. Если в текстовые логи случайно попадает бинарный контент, большинство редакторов вроде vim и less элегантно его обработают. Если же бинарный контент попадёт в неправильное место бинарных логов, ваши логи потеряны.Обоснованием хранения логов в бинарном формате были скорость и производительность, их легче индексировать и по ним быстрее искать. Однако это явно был трудный выбор с очевидными последствиями для конечных пользователей на обеих сторонах баррикад. Если требуются быстрые логи/логгирование, то их можно получить, но пользователям придётся выучить новую команду
journalctl, и они не смогут использовать знакомые инструменты.Мне бинарные логи не кажутся чем-то плохим, но это ещё один барьер для принятия systemd. Я рассмотрю логи позже в этой статье и представлю аргументы для своей точки зрения, что
journald является хорошей идеей.Хорошее
Теперь обратим внимание на преимущества, которые нам даёт systemd. Я думаю, именно они стали причиной, по которой все дистрибутивы Linux внедрили systemd.
Здравомыслие
Давайте начнём с того, что сравним init-скрипт SysV для ZooKeeper, который занимает 169 строчек хрупкого кода, как отмечено в комментариях по всему его исходнику.
# for some reason these two options are necessary on jdk6 on Ubuntu
# accord to the docs they are not necessary, but otw jconsole cannot
# do a local attach
...Реализуем его в виде юнита systemd:
[Unit]
Description=ZooKeeper
[Service]
Type=simple
Restart=always
RestartSec=5
EnvironmentFile=/etc/sysconfig/zookeeper
ExecStart=/usr/bin/java -cp ${ZK_CLASSPATH} ${JVM_FLAGS} org.apache.zookeeper.server.quorum.QuorumPeerMain ${ZOO_CFG_FILE}
[Install]
WantedBy=multi-user.targetЯ написал это менее чем за десять минут. Разумеется, ему требуется файл окружения, который устанавливает следующие переменные:
ZK_CLASSPATH=/opt/zookeeper:/opt/zookeeper/lib:/etc/zookeeper
JVM_FLAGS=-Xmx=2g
ZOO_CFG_FILE=/etc/zookeeper/zoo.cfgНо… это всё. Дело сделано.
Если этот процесс просто протоколируется в стандартную выдачу и стандартные ошибки, то логи будут сохранены в журнале, их можно отслеживать, индексировать, искать и экспортировать с помощью
syslog-ng или rsyslog. Ниже я рассмотрю, как записываются логи.Контроль за процессами
В прежние времена мы использовали что-то вроде supervisord для отслеживания, что процессы работают. Это потому что до появления systemd если вы это не напишете, то оно и не произойдёт. Не думайте, что скрипты init после запуска системных служб будут реально мониторить эти процессы, потому что такого не было. Сервисы могли вывалиться с ошибкой segfault и останавливались до тех пор, пока пользователь вручную не запустит их снова.
А теперь systemd:
[Service]
...
Restart=always
RestartSec=1Это говорит системе, что если произошёл сбой в процессе, то подождать одну секунду и всегда перезапускать его. Если вы указываете
stop для сервиса, то он останавливается до тех пор, пока вы снова не запустите его, как и ожидается от этой команды. Вдобавок, systemd записывает в лог, когда и почему произошёл сбой процесса, так что нахождение проблем становится простым и тривиальным.Планирование процессов
Возвращаясь с тёмные времена init-скриптов SysV, каковы были наши варианты для запуска сервиса после другого сервиса? Или дальше, каковы были варианты для запуска сервиса A после сервиса B, но перед сервисом C? Лучшим вариантом был такой:
while true ; do
if pgrep serviceB ; then
start_service
break
else
sleep 1
fi
doneДля запуска сервиса A перед сервисом C нужно было изменить init-скрипт сервиса C и добавить похожий цикл while для обнаружения и ожидания сервиса A. Не нужно и говорить, что это катастрофа.
А теперь systemd:
[Unit]
Description=Service A
After=serviceB.service
Before=serviceC.serviceИ это всё. Больше ничего не нужно делать. systemd создаст граф зависимости сервисов и запустит их в правильном порядке, и у вас гарантированно
serviceA запустится после serviceB, но перед serviceC. Что ещё лучше, так это drop-in юниты, о которых я скоро расскажу. Если коротко, то несложно включить дополнительный код в исходный юнит без необходимости переписывать код исходного юнита.Бонус: условия на запуск юнитов
systemd также делает простым задание условий на запуск юнитов:
[Unit]
Description=Service A
ConditionPathExists=/etc/sysconfig/serviceAЗдесь Service A запустится только если присутствует файл
/etc/sysconfig/serviceA. Существует много разных условий, и все они могут быть инвертированы.Бонус: параллелизм
Поскольку systemd знает порядок зависимостей для всех своих юнитов, то загрузка машины Linux с использованием systemd происходит гораздо быстрее, чем на старых init-системах. Это потому что systemd запускает сервисы, не имеющие зависимостей, в параллельном режиме.
Перегрузка юнитами
Как обсуждалось выше, systemd позволяет очень просто подгружать дополнительные конфигурации для заданного юнита, расширяя его. Скажем, нам требуется только запустить
rsyslog после запуска cloud-final. В свою очередь, cloud-final является последним этапом работы cloud-init.Исходный файл для
rsyslog.service находится в /usr/lib/systemd/system/rsyslog.service, но мы не будем редактировать этот файл. Мы создадим drop-in юнит в /etc/systemd/system/rsyslog.service.d/after-cloudinit.conf:[Unit]
After=cloud-final.serviceОкончательное название файла не очень важно, поскольку оно заканчивается на
.conf. Что бы ни определял этот файл, оно будет включено в оригинальный файл юнита. Этот маленький drop-in проверяет, что rsyslog не запускается, пока cloud-final.service не начался/завершился.Дополнение: Мне указали в твиттере, что systemd запускает эти файлы в алфавитном порядке. Чтобы сохранить порядок в хаосе, вероятно, хорошей мыслью будет добавлять им числовые префиксы, тогда появится вразумительный порядок, например,
%02d-%s.conf.Перезапись юнитов
Что, если нам требуется полностью удалить из юнита определённые части? Удаление осуществляется просто:
[Service]
ExecStartPre=Что мы сделали в этом юните для перезаписи, так это удалили все блоки
ExecStartPre из исходного юнита. Если мы добавим ещё одну строку ExecStartPre под пустой строкой, то можем указать наш собственный скрипт для предварительного запуска, который полностью отличается от предыдущего.Запись логов
Логи с systemd невероятно простые и поддерживают все функции и плюшки, какие только захотите. Если процесс просто протоколируется в стандартную выдачу и стандартные ошибки, то лог по умолчанию записывается в журнал. Поиск по этим логам затем тривиален:
$ sudo journalctl -u rsyslog.serviceЭто запустит браузер типа
less для сканирования истории rsyslog.service. Отслеживание лога для юнита тоже осуществляется просто:$ sudo journalctl -u rsyslog.service -fЭто буквально эквивалент команды
tail -f для лога.Логи автоматически проходят ротацию в журнале и это можно настраивать, так что больше никаких глупостей с
logrotate, журнал просто берёт всё на себя.Подключение
rsyslog или syslog-ng делается просто, и это означает, что больше ни одному из ваших приложений не нужно общаться с syslog, их стандартная выдача сразу идёт в журнал и будет импортирована и отправлена в соответствии с конфигурацией syslog.Идём дальше и учимся
Мы здесь рассмотрели много основных мест. Лично я сохранил в закладках следующие фрагменты документации для systemd, которые помогают мне писать юниты:
Мы даже не говорили о великолепных точках монтирования, таймерах и многих функциях безопасности, которые поддерживает systemd. Я также не упоминал об инструментах из пользовательского пространства
systemctl и journalctl, которые описаны здесь:Определённо, я долгое время был в лагере «systemd отстой», пока не начал изучать, что реально позволяет делать systemd. Теперь я рассматриваю systemd как неотъемлемую часть своей инфраструктуры на системном уровне, и её было бы всё сложнее реализовать на старых дистрибутивах без systemd.
Комментарии (174)
kx13
06.04.2017 13:09+3Это ломает привычные инструменты, которые мы привыкли использовать для мониторинга системы: tail, cat, less и grep становятся бесполезны.
У меня вопрос по поводу бинарных логов.
Ведь стандартные команды типа "journalctl -u rsyslog.service" все равно могут предоставлять вывод в текстовом виде. По сути получается, что все претензии сводятся к тому, что не хочется в конвеере лишнюю команду добавлять.
Если раньше надо было
"less /var/log/service.log", то сейчас надо "journalctl -u service |less". Ну и с остальными командами нечто похожее.
я что-то не вижу большой разницы кроме того, что надо запоминть еще одну команду и ее ключ.
По сути вся информация на диске хранится в бинаром виде, вся разница лишь в том как ее предоставить в читабельном виде.
andreymal
06.04.2017 13:25+1Если система не грузится даже в консоль (или если её грузить небезопасно по каким-то причинам), а хочется почитать логи для выяснения причины, как с какого-нибудь LiveCD почитать эти бинарные логи?
alexpolevoy
06.04.2017 13:36+2journalctl --file /path/to/file
kx13
06.04.2017 13:39что я и говорил, надо просто запомнить еще одну программку.
andreymal
06.04.2017 13:51+1Вместо простого универсального less нужно держать в голове ещё один аналог less и стопицот ключиков к нему для разных ситуаций :)
(Впрочем, я и не против, но блин, я уже несколько лет работаю с systemd, а ключики journalctl наизусть до сих пор не помню)kx13
06.04.2017 13:58+4Вместо простого универсального less нужно держать в голове ещё один аналог less и стопицот ключиков к нему для разных ситуаций :)
Это совершенно естественная ситуация для специалиста. Надо выходить за свой предел и учить новые команды и ключи.
Если человек осозает, что ему надо работать с командной строкой, то принять установку, что надо ВСЕ время учить новые команды, это первоочередная необходимость :)
Одни учат стишки, а другие команды и ключи :)
а ключики journalctl наизусть до сих пор не помню
миллионы людей работают с командой "ls", но не думаю, что они и половины ключей помнят. Знать все ключи восе необязательно :) Зря чтоли команду "man" придумали :)
kx13
06.04.2017 13:39+2Логи всегда читаются с помощью какой-то программки, например less. Технически никто не мешает авторам LiveCD положить рядом другую утилиту, например systemdlogless и можно пользоваться ей. Главное, чтобы пользователь знал про такую программу. Про ту же утилиту less человек узнает от других людей (посредством личной беседы или документации). Что мешает так же создать утилиту и распространять знания о ней?
Просто systemlog еще очень молод и не все выучили набор стандартных команд для работы с ним. Или еще не существует таких инструментов.
Поэтому бинарные логи — это не проблема systemd.
kt97679
06.04.2017 18:13Не проблема до тех пор пока в силу какого-то сбоя не порушилась структура файла.
Chupaka
06.04.2017 21:37+2Как только systemd обнаруживает порчу лога, он закрывает его и начинает новый файл. Структура повреждённого лога восстанавливается в памяти при обращении к нему (сам файл в read-only), что даёт возможность обновлением systemd добавить новые алгоритмы восстановления для старых файлов. А если данные совсем потёрты-потеряны — то какая разница, вы их не прочитаете из бинарного лога или из текстового? :)
linux_art
11.04.2017 18:02Из текстового можно вычленить хоть часть информации, а из бинарного в случае нарушения формата?
grossws
11.04.2017 20:06А утилитой
stringsизbinutilsвоспользоваться? Про неё на каждом втором ответе в гугле про "как прочитать journal, если нет journalctl" написано. Потом можно грепнуть, например, поMESSAGE.linux_art
11.04.2017 20:18-1А еще можно забивать гвозди микроскопом…
grossws
11.04.2017 20:21+1Вам, извините, с битым файлом работать или просто поговорить? Напомню, что вы заявили проблемой "вычленить хоть часть информации".
linux_art
11.04.2017 20:27Мне просто работать. А не заниматься нетрадиционными интимными отношениями с бинарными форматами и qr-кодами. Именно поэтому на моих серверах нету systemd и journald.
grossws
11.04.2017 21:04+1Если вам не приходится сталкиваться с проблемами, решение которых упрощает journald, то пользуйтесь старыми средствами, кто ж вам мешает?
При наличии journald, кстати, не возбраняется использовать их так же, как и раньше. Здесь в комментариях уже, кстати, не менее двух раз писали, что логи от сервисов прекрасно направляются в rsyslog/syslog-ng без каких-либо проблем. Достаточно не менять строчку
ForwardToSyslog=yesв/etc/systemd/journald.conf.
При чём здесь qr-коды в контексте этого обсуждения — мне вообще не понятно. Никто не запрещает:
- не собирать отображалку ключа для log sealing, а скопировать его руками (он просто отображается в консоли);
- не использовать log sealing, т. е. не дёргать
journalctl --setup-keys.
linux_art
11.04.2017 21:12Как я уже писал выше, мне не нужно заниматься этим онанизмом с дополнительными прослойками. В моем дистрибутиве нету systemd по умолчанию и даже при этом я столкнулся с противоестественными решениями Поттеринга на тему именования сетевых устройств например. И вынужден был тратить свое время чтобы решить эту проблему, которая не возникла если бы RedHat и Поттеринг не пропихиливали это поделие в каждую щель.
grossws
11.04.2017 21:20Хотя persistent naming меня самого несколько раздражают (в частности, из-за поведения vmware и virtualbox), но откуда ноги растут — известно и понятно.
На машине с одним сетевым адаптером оно просто не проявляется и вполне можно прописать
biosdevname=0 net.ifnames=0в cmdline ядра один раз и забыть.
На машине же с несколькими (особенно одинаковыми) адаптерами и/или сетевыми адаптерами, подключенными по usb, — ад, который как раз и решается persistent naming.
Как и проблема замены адаптера на такой же, но с новым MACом, которая раньше была довольно неприятной.linux_art
11.04.2017 21:23-1Проблема в том что МНЕ это не надо, но У МЕНЯ нет выбора. Кому это надо — можно включить, но по умолчанию это не нужно. А сейчас все кому это не нужно, коих сильно больше чем имеющих специфичные конфигурации вынуждены иметь дело с этим идиотизмом.
iborzenkov
06.04.2017 13:32+5Кстати по поводу бинарных логов это вообще аргумент людей, которые «не читал но осуждаю»
В syslog systemd умел писать с самого начала, а сейчас вообще при установки syslog из пакетов он автоматически конфигурирует все что нужно в systemd. А с учетом того что syslog обычно устанавливается, то конфигурация с journal будет скорее всего только в контейнерах, для которых собственно он и отличный вариант
dmitry_ch
06.04.2017 14:25+2«less /var/log/service.log», то сейчас надо «journalctl -u service |less»
Вы же понимаете, чем отличаются выражения
less log.txt
и
cat log.txt | less
На первый взгляд, то на то и получаем. Но, скажем, если лог у нас оказался реально большим (давайте добавим для усиления, что — большим, что размер ОЗУ), как вы думаете, какой вариант будет адекватнее к системным ресурсам?
Systemd кому-то хорош, кому-то плох, но этот холивар не разрастался бы до таких масштабов, если бы была возможность в системе выбирать, что юзеру больше нравится. Сегодня же имеет ситуацию, что многие дистрибутивы весело и безальтернативно перешли на systemd, так что людям, которым старый подход ближе, остается только либо кухарить в стиле without-systemd.org, либо переходить на что-то вроде devuan. Конечно, такие «альтернативы» не всем по душе, хотя ведь разговор сводится к личному выбору каждого.kx13
06.04.2017 14:43+1как вы думаете, какой вариант будет адекватнее к системным ресурсам?
В вашем примере скорее всего второй пример позатратнее будет (и то не факт), но опять же это лишь вопрос инструментов и привычек. Вместо старого любимого "less" заставляют пользоваться новомодным "<что-то-там>".
Любая инфрмация с жесткого диска считывается какой-то программой. Не важно как информация хранится на диске, важно, чтобы пользователю эта информация предоставлялась в удобном для восприятия виде, были инструменты для обработки этой информации и эта программа была всегда доступна. У чисто текстового формата одно приемущество: для работы с ним придумано множество инструментов (ввиду простоты этого формата) и многие о них знают и пользуются для других задач.
Systemd кому-то хорош, кому-то плох, но этот холивар не разрастался бы до таких масштабов, если бы была возможность в системе выбирать, что юзеру больше нравится
Людям лишь бы поспорить, если был бы выбор, то спорили какую систему поставить по умолчанию.
Если каждый будет выбирать, то будет еще хуже. Это, как минимум, распыляет ресурсы на поддержку нескольких систем. Если я разработчик пакета, то мне нужно два скрипта инициализации писать, я ведь не знаю, что там себе пользователь выбрал.
Холивар с systemd просто классический пример, когда людей заставляют переходить на что-то иное. Всегда находится тот, кому и старое все устраивало. Здоровый консерватизм, конечно, нужен, но не в ущерб прогрессу.
dmitry_ch
06.04.2017 15:01+3Любая инфрмация с жесткого диска считывается какой-то программой
В первом варианте информация считывается в объеме, необходимом для вывода. Во втором — считывается вся, грузится через пайп (что предполагает её хранение, как вы понимаете), и далее, при выводе, все продолжает храниться.
Все равно, что разница между «сходить в магазин за буханкой хлеба» и «привозом всего магазина домой, чтобы кушать хлеб по кусочку за каждый примем пищи».
Прогресс же… «Здоровый прогресс необходим, но если оно и так работало — зачем менять?» Это заявление и ваше «Здоровый консерватизм, конечно, нужен, но не в ущерб прогрессу» одинаково имеют право на существование. А получаем очередную революцию, когда пришли большевики, и сказали, что отныне будем жить по-другому.
Если каждый будет выбирать, то будет еще хуже.
Зря вы так. Кому хуже? Почему вы решили, что выбор безальтернативный — самый лучший?kx13
06.04.2017 15:29+3На сколько я знаю из пайпа тоже можно частями читать. Но это не важно. Костыли никто не отменял, но если надо быстро и эффективно, то сделают специальную утилиту, в принципе они уже есть.
одинаково имеют право на существование.
Право то имеют, только одна идея поддерживает прогресс, а другая регресс т.к. идие противоположные.
Поэтому одна идея ложная другая нет. Если развитие linux внедрение systemd не повредит, то значит правильно был сделан выбор в пользу systemd. Но это только время покажет.
А получаем очередную революцию, когда пришли большевики, и сказали, что отныне будем жить по-другому.
Так и получилось. Кому не нравятся пусть садятся на свой пароход и плывут в сторону "devuan", благо у нас опенсорс.
Почему вы решили, что выбор безальтернативный — самый лучший?
Потомучто я оцениваю ситуацию в целом и рассматриваю ситуацию с двух сторон.
Есть ситуации, когда отсутствие альтернатив — это лучший вариант, нужно взять что-то одно. И необходимо волевое решение, чтобы навязать это одно.
Если развивать вашу хлебную аналогию то получаем следующее.
Какой хлеб выбрать свежий(говорят, что свежий хлеб немного вреднее для желудка) или вчерашний, тоже неплох.
Оба вида хлеба выполняют свою задачу примерно одинаково. В данном случае нужно чтобы кто-то выбал одно из двух. В нашем случае это были разработчики дистрибутивов. Всякая "демократия" только пойдет во вред. Все дистрибутивы, не использующе systemd найдут свое место, но их доля будет ничтожна или очень нишевая.
Если бы хлеб был недопеченный, тогда никто в здравом уме не будет брать его.
Но systemd уже готов, конечно не лишен недостатков, но он более перспективен. Поэтому люди мыслящие более широко, его и выбрали.nikweter
06.04.2017 17:30Ну знаете ли, так можно договориться что windows уже готов и, хоть и не лишен недостатков, но более перспективен.
kx13
07.04.2017 07:48Кстати о windows.
Тот же windows8 был принят в штыки. Но ничего, Mirosoft немного подшаманил и windows10 уже был принят более благосклонно и вроде бы неплохо продается. Т.е. свои задачи выполняет.
А критика windows10 примерно такого же уровня как и systemd.
linux_art
11.04.2017 18:08Это тот Windows 10, про который только ленивый не пошутил «нет я не хочу обновиться»?
dmitry_ch
06.04.2017 18:05+3Ох уж мне эти «прогресс не остановить» граждане!
Вы еще скажите, что, раз новая версия ОС вышла, старые по всему миру нужно срочно снести и удалить. А заодно сжечь компы, на которых старые ОС эти установлены. А то нефиг — уже вышли новые компы, но эти новые компы и сервера (прогрессивные донельзя) никто не покупает!
Да что компы?! Я вот на улице каждый день вижу сотни и сотни не совсем новых машин. Даром, что машина 20 летней давности покрепче свежевыпущенной будет, даром, что свежие гниют (после взгляда на их металл) куда легче — менять (!!!), и никаких тут. Отобрать у владельцев, и пусть покупают себе новые! Конечно, за новые свои деньги — как раз и рынок застоя избежит.
Плохо, конечно, что сервера эти иногда стоят для дела, а не только для постоянного обновления. Но тут, конечно, тактика большевиков поможет: «кто не все — того накажем», прогрессом!
А что (говоря про пример с less) один человек внимательно в магазине выбирает, что купить, а другой (согласно вашему желанию) весь магазин к себе домой волочет, занимая и дорогу, и лифт в доме, и себе не давая жить (т.к. вся квартира завалена ненужным, но еще не отсортированным товаром) — да ведь ерунда, новую квартиру нужно искать. Идея-то хорошая, правда, все иметь под рукой, она явно имеет право на жизнь, а что её конкретная реализация подкачала — ну, это мелочи!
Возвращаясь к вашей аналогии, я бы сказал, что зачем против хорошо привычной схемы с init.d придумывать еще что-то, на что потратятся силы девелоперов? Люди годами (десятилетиями!) пишут привычные скрипты запуска, на всякую проблему уже куча костылей и решений придумано — оно работает, зачем ломать и вообще распылять силы сообщества? Вы что, скажете, разработчикам нечем заняться, кроме как переводить свои пакеты на новую систему (причем я её тут даже не пишу — через несколько лет, поверьте, придет новый «мессия.d», и про него все будут говорить точно то же, что уж он-то точно всех подружит.
Если развитие linux внедрение systemd не повредит, то значит правильно был сделан выбор в пользу systemd
Вы знаете, было бы правильнее сказать, что раз уж даже такое странное дело, как внедрение systemd, не развалило экосистему (хотя части людей и части серверов жить стало хуже), то идеи Unix показали свою глубинность и выдержали проверку не только временем, но иглуповеликими новыми мыслями.kx13
07.04.2017 07:37+1Ох уж мне эти «прогресс не остановить» граждане!
Есть объективные законы развития, нравятся вам они или нет.
Человечество с момента своего возникновения развивает свои средства производства. И все время будут появляться более сложные вещи. Надо к этому привыкнуть.
Вы еще скажите, что, раз новая версия ОС вышла, старые по всему миру нужно срочно снести и удалить.
Вы делаете неправильные выводы. Прогресс означает, что когда вы в следующий раз будете покупать что-то, оно будет уже гораздо более сложное и во многом более совершенное, а где-то наоборот может быть хуже. Но в общем развитие всегда идет.
Вспомните тот же Linux двадцатилетней давности и современный. Это практически две разные сыстемы. Linux развивается и усложняется, хочется отдельным индивидам это или нет.
Для меня лично, многие новые вещи тоже кажутся слишком преусложненными т.к. мои потребности удовлетоворяют вещи созданые 10-20 лет назад. Сейчас свобода, хочешь пользуйся новинками, хочешь не пользуйся. По большому счету никто не заставяет. Но не надо пытаться остановить паровоз прогресса.
Но тут, конечно, тактика большевиков поможет: «кто не все — того накажем», прогрессом!
Если я правильно понимаю, вы о большивиках знаете только из перестроечных агито :)
Возвращаясь к вашей аналогии, я бы сказал, что зачем против хорошо привычной схемы с init.d придумывать еще что-то, на что потратятся силы девелоперов?
Это очевидно. Т.к. нашелся человек, которому привычная схема была неудобно и у него были силы и возможности и он создал нечто иное. Эта схема работает много тысяч лет.
Systemd тоже не конец истории возможно лет через 30 ему что-то придет на смену, когда всем надоест писать для него костыли.
не развалило экосистему
Внедрение одного стандарта как раз сплачивает систему. И люди как раз показали силу прогресса.
Стандартизация и унификация как раз характерная черта развития.
Они смогли объединить силы для развития одного продукта. Да, не идеального, но уже одного на всех.dmitry_ch
07.04.2017 08:22+1Вы уж определитесь, мы про свободу и выбор, или про насильственное (точнее, безальтернативное — что важнее) внедрение нового везде:
Сейчас свобода, хочешь пользуйся новинками, хочешь не пользуйся. По большому счету никто не заставяет.
Я вот, скажем, хочу или не хочу — но не особо меня спрашивают, ОС ставится с тем, что ее создателям в голову пришло положить. Да и вы, вот, от имени человечества, говорите, что, мол, нефиг шагать не в ногу, и что переход на шагание строевым шагом только в ногу — прямо естественный шаг, и чтопри Коммунизмена следующем этапе развития средств производства только так и будем ходить.
Внедрение одного стандарта как раз сплачивает систему.
Неверно говорите. Напишите «еще одного стандарта», потому что, худо-бедно, стандартов хватало и до systemd, и хватит после.
Идея декларативного языка последнее время все шире распространяется везде. Это и хорошо, и плохо (по очевидным причинам), но вопрос не в этой модели, а в том, что старые подходы резко оказались забыты.
Тем более что «до основания, а затем» менять все, как кажется, не стоило. Ну, стали логи в бинарном формате хранить (хотя могли в текстовом виде) — экономия места на этом не скомпенсировала разрастание числа и объема фалов с котиками в интернетах, а вот сложность добавила. Но даже бинарные логи (я про новую идеологию в systemd, без скидывания логов в текстовые файлы) просматривать стало-то неудобнее.
Серьезно, я бы ожидал, что для новой системы запуска будет как-то логично хранить и вызывать логи запуска отдельных сервисов понятнее, чем раньше (ибо логи смотрятся очень часто). Запускаю софтину, «что-то пошло не так» — покажите мне простой командой логи последнего запуска же! Ан нет, мне пишут, натурально, что «что-то пошло не так, напишите вот такую команду с вот такими ключами» (существенно неудобную к написанию конструкцию — а она нужна часто), которая покажет не лог последнего запуска, анесколько
(и выбирая по числу, а не по логике запуска) последних строк из общего лога, где мне нужные строки могут быть, а могут и нет. Работа с логом в этой ситуации напоминает ремонт двигателя автомобиля через выхлопную трубу.
Но, да, конечно, когда система знает о связи всех юнитов (и даже может параллельно их запускать), это отлично. Когда следит за работой ПО в системе — тоже неплохо. Когда она становится монолитным комбайном не Unix-way — тут и начинаются вопросы.
Я лично, признаться, жду, когда появится приемник systemd. Год-два, конечно, это займет (не 20-30 лет), но этом systemd-ng, будем надеяться, могут быть решены некоторые вещи.
Но, повторю, когда мне насильственно и безальтернативно ставят внутрь машины новую столь важную систему, это несколько «широко» получается. Ну, понятно, что надо было что-то отвечать MS, когда последние выкорчевали меню «Пуск» в 8-ке, но все же — выбор-то должен быть!kx13
07.04.2017 08:50Вы уж определитесь, мы про свободу и выбор, или про насильственное (точнее, безальтернативное — что важнее) внедрение нового везде
Ответ здесь не однозначный с одной стороны у каждого есть выбор, с другой если вам чего-то, чего нет в списке выбора, то вам не повезло.
Если вы используете ОС для своих личных целей, пользуйте то, что вам нравится, есть куча ОС и дистрибутивов на любой вкус.
Если вы на работе, то небходимо использовать ту ОС которая максимально эффективно решает поставленную задачу (или ее выдали по каким-то коньюктурным соображениям). В общественном труде вкусы одного человека не играют роль, важны интересы коллектива (или его руководителя). А что там у нее внутри ОС это проблема специалиста, который будет ее настраивать.
Поэтому с одной стороны у вас есть выбор, а с другой нет. И так везде.
Ну, стали логи в бинарном формате хранить
Бинарные логи это вообще побочный функционал. Преимущество systemd далеко не в этом. Были бы текстовые логи, сути это бы не меняло.
Ан нет, мне пишут, натурально, что «что-то пошло не так, напишите вот такую команду с вот такими ключами»
Это просто брюзжание. Вам ведь надо узначть, что случилось. Напишите команду и узнаете в чем проблема. Несколько раз повторите, будете ее на память помнить как и less. Это лишь вопрос привычки.
У вас общий подход неверный. Когда мне надо разобраться с новой программой (установить, настроить, починить), для меня наоборот это интересно. Узнаю что-то новое, обновлю свой багаж. Если я запомню еще пяток команд мне это не повредит. Я же не еще один кирпич в сумке буду носит :)
но все же — выбор-то должен быть!
Используйте FreeBSD :)
VolCh
07.04.2017 09:53Несколько раз повторите, будете ее на память помнить как и less. Это лишь вопрос привычки.
Во-первых, это надо уже помнить две команды. Во-вторых, есть такой нюанс, как исчерпание коротких и(или) запоминающихся имён команд, они уже заняты, и получаются всякие systemctl и journalctl, которые и запомнить сложнее, и выговорить, и тупо набирать дольше, что, в том числе, увеличивает количество опечаток и подобных ошибок.
develop7
07.04.2017 10:15+1Во-первых, это надо уже помнить две команды.
а до этого надо было помнить пути к файлам с нужными логами.
dmitry_ch
07.04.2017 09:54Используйте FreeBSD :)
Это лихо Вы! Это вы перечеркнули всю свою логику, и правильно!
Итак, имеем промышленную систему, специалиста (-ов) для её обслуживания, и новый софт, который лучше-ярче-молодежнее старого. Конечно, спецы разберутся, как заставить новую программную систему работать более-менее вместо старой, но при этом в промышленную систему будут внесены изменения, которые потребуют время и силы на тестирование. Я выше про машины писал, что, мол, отобрать у владельцев старые машины, пусть купят новые — то же и здесь, вы (в рамках вам любезного прогресса) решили, что людям нужно что-то новое, и решили принудительно внедрить это. Люди, конечно, скажут спасибо, и будут рады изменить свои планы, потратив ресурсы не на то, на что планировали, а на выполнениевашей блажитребований прогресса.
Ваш багаж никто не собирается ограничивать. Но совместимость, согласитесь, при вводе серьезных изменений, вещь как раз полезная, а не вредная.
Пока из важных изменений вижу только написание скриптов/юнитов/еще чего-то для запуска ПО в разных системах инициализации/управления. Но Вы и сами знаете, что писать их нужно довольно редко (грубо говоря — по разу каждый, а дальше как очень понадобится), так что большой нагрузки на мейнтейнера это не наложит. А вот нагрузку на тысячи специалистов и систем внедрение кардинально новой system-wide софтины наложит, и еще как.
В общем, революции (как говорят апологеты каждой) делаются не на пустом месте. Но цена каждого революционного изменения бывает куда выше, чем эти апологеты считают. systemd — это не поворот сибирских рек, пользы от него не так много, конечно, но по аналогии, и вреда от его невведения было бы меньше.develop7
07.04.2017 10:34+2вы (в рамках вам любезного прогресса) решили, что людям нужно что-то новое, и решили принудительно внедрить это
"принудительно внедрили" systemd как раз maintainerы дистрибутивов. Затем, чтобы сэкономить себе времени на поддержку.
Жить не можете без тёплых ламповых батников — не обновляйтесь или переходите на дистр без systemd или поддерживайте форк дистра. Всё за свой счёт.
grossws
07.04.2017 12:27+1Я вот, скажем, хочу или не хочу — но не особо меня спрашивают, ОС ставится с тем, что ее создателям в голову пришло положить. Да и вы, вот, от имени человечества, говорите, что, мол, нефиг шагать не в ногу, и что переход на шагание строевым шагом только в ногу — прямо естественный шаг, и что при Коммунизме на следующем этапе развития средств производства только так и будем ходить.
У вас всегда есть свобода собрать свой дистрибутив, если вас не устраивают существующие.
Мейнтейнеры вам ничем не обязаны. Они часто тратят своё личное время, и его экономия при использовании systemd'шных unit'ов является достаточно значительной, чтобы на него переехать.
Вон devuan'овцы (типа debian без systemd от "veteran unix admins") денег собирают с хейтеров, которым нужен debian с sysvinit, можете присоединиться к их инициативе. Возможно, получите debian jessie с заменой systemd на sysvinit. Если он, конечно, выйдет. То что-то они долго udev пересобирают и init-скрипты пишут.
Что-то когда ck2 подыхал в муках, никто не пришел его спасать. Ни деньгами, ни вложением своих сил в его починку и развитие. Зато на заменивший его logind воплей выше крыши (в стиле "ааа, наш gnome3 зависит от systemd").
ValdikSS
08.04.2017 12:15+4Но даже бинарные логи (я про новую идеологию в systemd, без скидывания логов в текстовые файлы) просматривать стало-то неудобнее.
А по мне, стало гораздо удобнее. Я запускаю конкретный юнит командой, я могу посмотреть логи конкретного юнита. Мне не нужно куда-то там лезть в /var/log, думать, какой файл мог создастся.
Может, вам не нравятся длинные команды? Мне они тоже не нравятся, я сделал алиасы:
alias 'stop'='sudo systemctl stop' alias 'start'='sudo systemctl start' alias 'restart'='sudo systemctl restart' alias 'status'='sudo systemctl status'
Запускаю софтину, «что-то пошло не так» — покажите мне простой командой логи последнего запуска же!
Согласен, было бы куда проще, если бы при неудачном запуске показывалось 5-7 строк из лога.
9660
07.04.2017 10:47-1Разработчик или майнтейнер?
И да, когда старое прекрасно работало, а новое не дает никаких преимуществ это раздражает. Тянуть к прогрессу за уши плохая идея, нужно показывать преимущества чтобы пользователь пришел самостоятельно.develop7
07.04.2017 13:01+2нужно показывать преимущества чтобы пользователь пришел самостоятельно.
Показываю с выражением:
- пользовательские юниты
- невозможность сбежать от супервизора
- возможность покрутить вагон ручек, и как ни в чём не бывало пережить апдейт пакета
9660
07.04.2017 14:29Без обид но.
1. Ровно тождественно скриптам в init.d
2. Есть различные runit, daemontools и прочие супевизоры
3. Не нужно. Не то место чтобы чего то крутить. Стартовали — запустили. Все — миссия исполнена.grossws
07.04.2017 15:40+1- Что в слове пользовательские вам показалось непонятным? Пользовательские лежат не в
/etc/systemd/system//usr/lib/systemd/system, а в$XDG_CONFIG/systemd/usr. - Умеют ли они в cgroups и/или другие способы отслеживания всех потомков процесса на эффективно неограниченную глубину (про "умеют ли в зависимости" даже не спрашиваю)?
- Если у вас сервисы настолько тривиальны, что вам это не нужно, используйте runit. Хотя, наличие этих ручек не ухудшает UX.
9660
07.04.2017 15:501. Мне как раз все понятно. Пользовательские лежат в хоуме пользователя аналогично как это сделано у крона. init.d ничуть этому не мешает.
2. Умеют. Они для этого и созданы. Зависимости не их задача, их дело отследить и поднять упавшее.
3. Не ухудшает. Но преимуществом является далеко не всем.
Я же сразу написал «когда старое прекрасно работало, а новое не дает никаких преимуществ это раздражает». Когда нужно просто стартовать систему все эти выверты как правило не нужны. Даже параллельный старт, вещь по сути хорошая, особенной пользы не несет.
И вдруг внезапно предлагают — меняйте все, используйте это. Не дав никаких практических преимуществ кроме осознания приобщения к прогрессу.
Да нафик нормальному человеку этот прогресс, ему нужна стабильность и минимум телодвижений при обновлении.
Отсюда и весь негатив. Никто не против самого системд, весь срач за безальтернативность оного.Erelecano
08.04.2017 03:03+1> Пользовательские лежат в хоуме пользователя аналогично как это сделано у крона.
Правда что ли? Давно ли у крона они переехали из /var/spool/crontab/USERNAME к пользователю в дом? Смешно видеть, как человек не знающий элементарных вещей пытается критиковать что-то серьезное.
- Что в слове пользовательские вам показалось непонятным? Пользовательские лежат не в
develop7
07.04.2017 15:48+2- нужно. например, чтобы слегка протекающий сервис не уронил систему в своп (ограничили память, сервис тёк-тёк и упал от недостатка, перезапустился, работает дальше). Или ionice подкрутить. Или 50% от одного CPU оставить. Или вообще подсунуть readonly
/. Или запускать только при подключении определённого устройства.
- нужно. например, чтобы слегка протекающий сервис не уронил систему в своп (ограничили память, сервис тёк-тёк и упал от недостатка, перезапустился, работает дальше). Или ionice подкрутить. Или 50% от одного CPU оставить. Или вообще подсунуть readonly
pansa
07.04.2017 01:31+2> На первый взгляд, то на то и получаем. Но, скажем, если лог у нас оказался реально большим (давайте добавим для усиления, что — большим, что размер ОЗУ), как вы думаете, какой вариант будет адекватнее к системным ресурсам?
И на второй взгляд тоже =)
Если вы намекаете, что во втором случае весь файл будет помещен в память — вы ошибаетесь. Проверить это не составит труда.
Но к пожарной безопасности это не имеет никакого отношения, как говорил Остап =) Systemd, при всех огрехах, безусловное добро.linux_art
11.04.2017 20:38Безусловное добро он только при одном условии — он хорошо ложится на ваш юз кейс. Все поделки Поттеринга отличаются этим свойством. Всем остальным же они ломают всё. Зависимости, годами работающие системы и т.д.
kx13
06.04.2017 13:33+9Как и любая система, основанная на декларативном языке, systemd удобен и эффективен, где ваши задумки укладываются в то, что предусмотрели авторы. Шаг в сторону, начинаются проблемы. Плюс в том, что авторы предусмотрели очень многое.
Для простых задач systemd отлично подходит, скопипастил файлик, подправил пути, названия и сервис готов.
Никогда не создадут систему, которая будет всем нравится. Systemd решила многие существующие проблемы, значит надо пользоваться.
А нудеть, что "мы не можем теперь смотреть логи с помощью less" — это детский сад.
Иметь одну систему инициализации для многих дистрибутивов очень удобно. Один и тот же файл запускает сервисы на разных дистрибутивах.
develop7
06.04.2017 13:37+1А нудеть, что "мы не можем теперь смотреть логи с помощью less" — это детский сад.
а пикантности добавляет тот факт, что логи смотрятся именно с помощью $PAGER
sotnikdv
06.04.2017 13:36+5> Обоснованием хранения логов в бинарном формате были скорость и производительность, их легче индексировать и по ним быстрее искать.
Да мне, как администратору, до звезды скорость поиска, я их не читаю каждую секунду, я их читаю, когда у меня что-то сломалось. Медленно и построчно. И простые команды вполне себе помогают и текстовые процессоры. Есть индексация и быстрый поиск, хорошо. Нет — не смертельно.
А вот потеря логов — это пи!#$%ц!!! Задача логгера — НАДЕЖНО ЛОГИРОВАТЬ, это его основная функциональность. В духе unix way можно было прикрутить и индексацию и поиск и чего хотите сбоку. Хоть Stash. И оставить логгирование надежным. Прикрутить метадату и движок отдельно.
А пока что все, что я получаю от systemd, это иногда отсутствие логов, когда система грохнулась. Или отсутствие или повреждение. Что меня здорово подводило в самых неожиданных местах, от ковыряния андроида и до исследования смерти сервера.
И все бенефиты от бинарных логов, с таким подходом, бесполезны. Основная функция сломана.
В остальном к systemd претензий нет, за исключением того, что это «25-й стандарт USB», теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service. Уже или галстук, или трусы…alexpolevoy
06.04.2017 13:47Бинарные логи, кстати, тоже можно сделать относительно надёжными. Современные архиваторы умеют так делать. Стойкость, конечно, не стопроцентная, но после мелких повреждений вернуть к жизни тот же 7z или rar не составляет особого труда, если при его создании была заложена инфа для восстановления.
sotnikdv
06.04.2017 15:08+3Еще раз, проблема потери логов и повреждения логов, она разная. Причина одинаковая, внезапно крешнулось ядро или хардварь, но ведет к разным проблемам.
Т.е. или сервис вообще не успевает начать сброс буферов, тогда логи просто все.
Или запись обрывается внезапно. И если для текста это некритично, то прерванная перезапись\аппенд блока в бинарной базе эту базу повреждает.
Можете писать любую избыточную информацию, проблема в незаписи блока или обрыве блока и последнее для бинарного формата критичноalexpolevoy
06.04.2017 15:15+2Аудио/видеокодекам это не мешает использоваться для стриминга, где и теряется, и не дописывается постоянно. Это критично уже для админа, которому потом разгребать последствия сбоя, но никак не для самого формата. Ну, и текст тоже может не записаться, от этого страховки тоже никакой. Система не успела сделать sync перед отключением питания — и всё, можно помахать ручкой хоть текстовым, хоть бинарным данным.
nike38rus
06.04.2017 21:01+1Если уж вы так сильно уповаете на системные логи — гораздо надёжнее настроить их пересылку на какой-нибудь централизованный сервер в syslog/rsyslog/systemd и там уже хранить их как душе угодно, благо systemd умеет это. И получится гораздо удобнее чем тем же rsyslog читать файлы с диска и через udp или tcp гнать их на другой сервер для хранения
g0dlike
06.04.2017 13:51+2Да, сталкивался с тем, что в случае поврежденного файла с логами, они не просто были потеряны, они дальше не могли туда записываться — что чинилось ручным удалением битого файла.
Соглашусь, для скорости и фич у меня есть ELK, текущая имплементация бинарных логов кажется мне ужасной.
kx13
06.04.2017 13:53+2А вот потеря логов — это пи!#$%ц!!! Задача логгера — НАДЕЖНО ЛОГИРОВАТЬ,
Надежность хранения и текстовый формат понятия ортогональные.
Не надо их приравнивать. Наоборот в бинарном формате можно сделать коррекцию ошибок и дублирование данных и прочие плюшки.
Никто (я по крайней мере такого не слышал) ведь не жалуется на низкую надежность баз данных, из-за того что они свои данные хранят в бинаром виде :)
Проблема не в формате, а в инструментах. Так же бывали случаи, когда файл с текстовыми логами поврежден и не записан. В этом случае нужен статистический анализ. А если что-то у кого-то ломается, это не повод всем не делать так же.
Обсуждается система, которая используется миллионами, поэтому и оценивать ее нужно соответственно.
теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service.
Даже без systemd уже странно держать две системы инициализации. С третьей, конечно еще веселее.
sotnikdv
06.04.2017 15:13-1Ну не поможет коррекция ошибок при прерывании записи блока, не поможет.
И оборванная на записи строка несет информацию, а оборванная бинарная запись встроенными средствами не отображается в текущей реализации, сырые данные не показывает.
Плюс потеря данных, которые вообще не записались. Особенность дизайна systemd. Может уже пофиксили.kx13
06.04.2017 15:33+2Мы с вами рассуждаем очень отвлеченно. Может случится то, может случиться се. Может случится все, что угодно и даже текстовые логи не помогут.
Важно другое, systemd развивается баги лечатся, поэтому они могут и будут исправить ошибки. Наверняка недовольных надежностью записей много поэтому если будет кому заняться это пофиксят. Но не использовать systemd из-за логов, это странно т.к. это не основной функционал, и как уже говорилось systemd и обычный текст может писать.
linux_art
11.04.2017 20:44-2А чего стоят идиотские названия устройств типа enp1s0 вместо обычного eth0? Появилось когда втащили UDEV в кодовую базу SystemD. Лечится естественно статичным переименованием, но зачем было ломать то что работало десятилетиями?
surefire
06.04.2017 13:56теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service. Уже или галстук, или трусы…
Это проблема вашего дистрибутива, а не systemd. А в прогрессивных дистрибутивах такой проблемы нет, они уже давно целиком перешли на systemd без костылей.
sotnikdv
06.04.2017 15:10+1А можно узнать список этих восхитительных дистрибутивов? Ubuntu, Дебиан и RHEL нифига не перешли, а это основные дистрибы AFAIK.
iborzenkov
06.04.2017 15:35+1Вы это, обновляться пробовали?
ubuntu — 16.04
debian — с jessie
rhel — с 7
Дефолтными между прочем, разумеется сохранив совместимость с sysV и upstart для убунты.
Арч даже поддерживает и гента только не по дефолту.
Вот честно давно чистый дебиан не юзал — все убунта, но уже около все на systemd без проблем, в начале разумеется он еще скрипты стартовал, сейчас ок, и centos на вертуалке проекта — там тоже systemd дефолтно, тут вот на работе хейтеры в ужасе, но они линкс только в виртуалках видели из под макоси, им простительно.VolCh
06.04.2017 16:00-1Между "дефолтными" и "целиком" есть разница. Целиком подразумевается, что нет "совместимость с sysV и upstart для убунты"
iborzenkov
06.04.2017 16:06Целиком вы подразумеваете что выпилят поддержку всего остального?
Так этого не будет, если есть система инициализации в дистрибутиве — ее будут поддерживать.
Вот когда похоронят upstart и sysV то тогда и выпилят. Ну а так уже отдельные новые пакеты не пишут скрипты для sysV оставляя только файл для systemd.
iborzenkov
06.04.2017 16:20А, дико извиняюсь, посмотрел на свою ubuntu 17.04
sysvinit в репе отсутствуют — только утилиты остались
upstart есть, но дефолтным его можно поставить только ручками
ну конфиги будут подчищать потихоньку из пакетов
sotnikdv
06.04.2017 16:27+2Т.е. вы хотите сказать, что в перечисленных вами дистрибутивах нет «теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service»?
Т.е. нет ничего кроме systemd и все службы управляются через него? И service больше не используется для управления службами?
Ну так давайте же посмотрим на вашу 16.04. Обратите внимание на вывод service
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION=«Ubuntu 16.04 LTS»
dev / # find /etc -name *upstart*
/etc/logrotate.d/upstart
/etc/network/if-down.d/upstart
/etc/network/if-up.d/upstart
/etc/init/upstart-udev-bridge.conf
/etc/init/upstart-socket-bridge.conf
/etc/init/usb-modeswitch-upstart.conf
/etc/init/upstart-file-bridge.conf
/etc/X11/Xsession.d/99upstart
/etc/X11/Xsession.d/00upstart
/etc/linuxmint/adjustments/upstart.execute
/etc/upstart-xsessions
/etc/cron.daily/upstart
dev / # du -sh /etc/init.d
428K /etc/init.d
dev etc # service unbound status
? unbound.service
Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled)
Drop-In: /run/systemd/generator/unbound.service.d
L-50-insserv.conf-$named.conf, 50-unbound-$named.conf
Active: active (running) since Mon 2017-03-27 03:51:31 PDT; 1 weeks 3 days ago
Docs: man:systemd-sysv-generator(8)
CGroup: /system.slice/unbound.service
L-6726 /usr/sbin/unbound
Это я еще ни слова не говорю про RHEL.
В итоге — см изначальное сообщение.iborzenkov
06.04.2017 17:31+1«теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service»
Именно что нет, это было в убунте 16.04 до его выхода в релиз — там как раз в альфе немного службы отваливались.
Нету ни sysV ни upstart, то что вы показали с upstart — остатки от пакетов, которые к 16.10 были почищены, потому что у них стояла задача поддержки, а не выпиливания всего.
service кстати не костыли, а врапер для тех кто привык, юзает он systemd
В вашем понимании полная поддержка это не установленная по умолчанию, и полностью рабочая система, а выпиленные все остальные?
Окей, тогда 17.04 вполне себе подходит — они полностью выпилили sysV, его даже в пакетах нет.
$ find /etc -name *upstart*
zsh: no matches found: *upstart*
dev / # du -sh /etc/init.d
428K /etc/init.d
И что вы хотите этим сказать? у systemd есть слой совместимости с sysV, а тогда не все пакеты перешли еще, сейчас в два раза меньше уже, и то с учетом поставленного стороннего.
А что вы не хотите про RHEL говорить?
CentOS Linux release 7.3.1611 (Core)
du -sh /etc/init.d/*
4.0K /etc/init.d/README
16K /etc/init.d/functions
0 /etc/init.d/jexec
4.0K /etc/init.d/netconsole
8.0K /etc/init.d/network
develop7
09.04.2017 12:10+2? unbound.service Loaded: loaded (/etc/init.d/unbound; bad; vendor preset: enabled) Drop-In: /run/systemd/generator/unbound.service.d L-50-insserv.conf-$named.conf, 50-unbound-$named.conf Active: active (running) since Mon 2017-03-27 03:51:31 PDT; 1 weeks 3 days ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/unbound.service L-6726 /usr/sbin/unbound
вообще-то это вывод
systemctl
Zibx
06.04.2017 15:53Бинарный формат — это не только скорость поиска\индексирование, это ещё и скорость записи. То что данная реализация так косячит — не является проблемой подхода. Естественно в главу угла при реализации логгера надо ставить надёжность.
sotnikdv
06.04.2017 16:16Бинарный формат не будет быстрее, т.к. имеем те же текстовые данные плюс хидеры формата. Кроме случаев сжатия. Поля типа времени или уровня ошибки — разница в байты. И плюс индексация.
> То что данная реализация так косячит — не является проблемой подхода
А никто и не утверждал обратное, см. начальный комментарий.
ValdikSS
08.04.2017 12:22+3Что у вас за файловая система, что логи systemd-journald повреждаются?
В прошлом году отлаживал падения и зависания ядра, очень долго и нудно, компьютер зависал минимум сто раз, и база не повреждалась. У меня ext4, в нем, как во всех современных файловых системах, есть механизм журналирования и транзакций. Если какой-то блок информации попытался записаться на диск, и в это время произошло что-то фатальное (упало ядро), то блок просто отбросится при попытке чтения и удалится при первом же fsck.
bear11
06.04.2017 13:38-5А мне не нравится только то, что он сидит на PID 1 и я его никак и ничем не могу контролировать и не могу его перезапустить. Конкретнее напрягает то, что он очень большой и слабопроверямый. Хорошо бы написать какой-нибудь простой враппер, который бы сидел на PID 1 и транслировал бы все сигналы и возвраты зомбей к запущенному им systemd, но который мог бы запускать также и доверенные, не подчиняющиеся systemd процессы.
kx13
06.04.2017 13:43+1он вроде бы как-бы замена стандартному init, который с самого начала сидел на PID=1
Конкретнее напрягает то, что он очень большой и слабопроверямый.
Любая программа такого уровня большая и сложнопроверяемая. Не думаю, что SystemV init сильно проще, он просто переносит часть сложность на разработчиков скриптов инициализации.
NiTr0_ua
06.04.2017 17:27-2в нем нет функций журналирования, мониторинга, горячей подгрузки модулей, и прочего того что не должно быть в init'е. и падение логгера или monit'а к примеру не вызовет краш всей системы (в отличие от падения systemd).
а помесь пылесоса, кофеварки и холодильника, с прилепленным на всякий случай сбоку вибромассажером — в любом случае будет выполнять свои функции куда хуже, чем эти приборы по отдельности.grossws
06.04.2017 21:48+3в нем нет функций журналирования, мониторинга, горячей подгрузки модулей, и прочего того что не должно быть в init'е. и падение логгера или monit'а к примеру не вызовет краш всей системы (в отличие от падения systemd).
Вы только на LOR'е про systemd слышали?
systemd-journald— это отдельный процесс, он не в PID1. Видели ли вы "вживую" падение systemd pid1 (given живая fs)?NiTr0_ua
06.04.2017 22:06-3Вы только на LOR'е про systemd слышали? systemd-journald — это отдельный процесс, он не в PID1.
ну особо его палочкой не тыкал. на десктопе его у меня нет, на серверном хозяйстве — тоже.
а монстр «все в одном» — тупиковый путь развития. больше кода — больше ошибок, выше вероятность падения. не?
Видели ли вы «вживую» падение systemd pid1 (given живая fs)?
https://access.redhat.com/security/vulnerabilities/2679271 к примеру. тупейший баг, да.
и да, при мертвой (или ушедшей в рид-онли) ФС init тоже не должен падать. хотя бы потому, что в этот момент может быть живой шелл, через который сисадмин пытается диагностировать/пофиксить удаленно проблему. а после смерти инита из-за ФС — система просто не сможет забутиться.grossws
07.04.2017 00:53+4а монстр «все в одном» — тупиковый путь развития. больше кода — больше ошибок, выше вероятность падения. не?
Оно, благо, модульное. Но многих хейтеров это не останавливает, и они начинают кричать, что systemd/pid1 содержит/зависит от libqrencode, http client, dhcp client, ntp client и кучи другого барахла, которое можно: а) не включать при сборке, б) не использовать.
Некоторые вещи типа обязанностей pid1, работы с cgroups и namespaces, обработки зависимостей и слежения за сервисами-детьми (которое, хоть и в меньшей мере, необходимо в pid1, т. к. переусыновлять и рипать зомби — обязанность pid1). Получается более сложная штука, чем bsd sysv init, но вполне сравнимая с upstart'ом и более продвинутая технологически, что сильно упрощает жизнь advanced пользователям.
Часть вообще заявляет, что на десктопе и серверах (не в embedded) им хватает runit'а. Ума не приложу как (он не умеет в зависимости вообще, хотя в баше можно накостылять тривиальные случаи). Правда, эти пользователи по совместительству были хейтерами systemd и на объективность рассчитывать не приходится.
и да, при мертвой (или ушедшей в рид-онли) ФС init тоже не должен падать. хотя бы потому, что в этот момент может быть живой шелл, через который сисадмин пытается диагностировать/пофиксить удаленно проблему. а после смерти инита из-за ФС — система просто не сможет забутиться.
CVE'шки, на которые вы дали ссылку совсем не про это, они про локальный DoS, требующий кривого notify от сервиса. Баг, конечно, ощутимый, но такое со временем подчистят.
Как кстати,
upstart, который многие любят, ведёт себя при большом потоке inotify знаете? Мне их kernel panic из-за упавшего pid1 очень не понравилась в своё время. Благо, на ноуте, а не на сервере.VolCh
07.04.2017 09:59-2более продвинутая технологически, что сильно упрощает жизнь advanced пользователям.
Но усложняет жизнь обычным пользователям. С init достаточно было знать азы bash, чтобы написать обвязку для своего демона, теперь же надо штудировать маны, разбираться в синтаксисе и флоу, при этом азы bash знать нужно всё равно.
develop7
07.04.2017 10:43вообще-то обычные пользователи тупо копипастят юнит из интернетов, и это если его нет в пакете с софтиной
VolCh
07.04.2017 11:53-2Ключевая фраза "для своего". Что я могу скопипастить для демона, которого закончу писать через пару часов?
develop7
07.04.2017 12:52+3примеры из https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit_Files.html (гуглится, кстати)
VolCh
07.04.2017 15:40-4Несколько часов на демона и несколько часов на его systemd обвязку?
grossws
07.04.2017 15:45+2Вы пробовали? Или так, от балды "несколько часов на его systemd обвязку"? У меня первое написание unit'а заняло меньше 15 минут, благо в man'ом пользоваться умею.
VolCh
07.04.2017 15:50+1Оценил объём текста по вашей ссылке. Причём, навскидку, нужно ознакомиться со всем девятым разделом, а не только 9.6, если хочется хотя бы минимально понимать как systemd работает.
develop7
07.04.2017 15:50+2к счастью, ритуальные танцы для написания именно демонов systemd также упразднил
grossws
07.04.2017 12:07+2И обычные пользователи типа, скажем Atlassian с этим откровенно не справлялись. Хотя азы баша они явно знают.
Ну и как разработчик, скажу, что мне systemd очень сильно упрощает жизнь. Как вспомню
start-stop-daemonи подобное барахло, абсолютно невнятную систему зависимостей sysvinit'а и прочие подобные радости, так убивать хочется.
kx13
07.04.2017 07:46+2что не должно быть в init'е.
Вроде бы нет стандарта на то, чего не должно быть.
Поэтому авторы добавляют то, что считют нужным. Обычно это то, что всегда присутствует в системе.
Suvitruf
06.04.2017 14:01+2В прежние времена мы использовали что-то вроде supervisord для отслеживания, что процессы работают.
[Service] ... Restart=always RestartSec=1
А в supervisord не тоже самое? Мы его, к слову, до сих пор используем.
[program:api] autostart=true autorestart=true startretries=3
Godless
06.04.2017 14:40+2Уважаемые гуру системд. Как грамотно запускать сервис после полной инициализации сети? Проблема в том, что сквид например через раз сокет нормально инициилизирует, потому что интерфейс поднялся, а адрес еще не назначен. Писать After=network-ready.service не помогает.
ruslan_sem
06.04.2017 16:37Cейчас под рукой нет линукса, но нужно писать что-то вроде After=network-online.service или там даже большие буквы есть, типа Network-online.service, нужно смотреть в папке с юнитами
varnav
07.04.2017 11:57А гарантированного способа нет, network-online.target ближайшее что есть. Рекомендуется писать сервисы так, чтоб они нормально понимали отсутствие сети.
mozg1986
06.04.2017 15:25Ну а у меня следующий вопрос. Имеется софтина, которая меняет правила iptables, сформированные shorewall-ом, при запуске и останове. Требуется, чтобы при перезапуске shorewall эта совтина останавливалась, ждала перезапуска shorewall, а потом снова запускалась. Как это можно реализовать в виде зависимостей?
snp
06.04.2017 20:14Думаю, что-то такое (и, соответственно, старт/стоп/рестарт делать на
foo.target):
foo.target:
[Unit] Description=Foo service group [Install] WantedBy=multi-user.target
shorewall.service:
[Unit] Description=Shorewall PartOf=foo.target [Service] # … [Install] WantedBy=foo.target
bar.service:
[Unit] Description=Bar PartOf=foo.target After=shorewall.service [Service] # … [Install] WantedBy=foo.target
sebres
06.04.2017 15:59+5systemd-escape
может просто не надо писать баш-скрипты в systemd?
Т.е. я про то, почему это должно быть непременно частьюsomething.service, а не частью напримерsomething.sh, который отробатывает в ExecStart...
IMHO systemd-escape сделана как helper, чтобы писать динамические systemd-скрипты (т.е. не руками, а "машинным" способом).
evgenWebm
06.04.2017 17:26Половина, тех кто за или тех кто против. Если не большинству, вообще без разницы что используется, СистемДи или не СистемДи.
Но они, с пеной у рта доказывают, что СистемДи плохой/хороший.
Не смешно ли?
throwaway88
06.04.2017 17:27+4SystemD отстой, да здравствует SystemD
И почему только эту ошибку допускают так часто?
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple.
pkuutn
06.04.2017 19:58+1С моей точки зрения, проблема заметно шире, чем systemd.
Она затрагивает большУю часть свободного ПО.
Вероятно, связана она с тем, что большинство программистов имеют довольно высокий интеллект.
И, соответственно, очень любят решать сложные задачи. А рутинные и несложные — не любят.
А в реальной эксплуатации сложные задачи и проблемы возникают редко.
Но мы получаем набор элегантных решений для сложных проблем — вместо вылизанных до блеска решений проблем рутинных.
systemd — просто очень яркий пример. К примеру, одно из преимуществ systemd — параллельная загрузка, уменьшает время старта системы. Какому количеству пользователей это полезно? Как часто вы перезагружаете свои железные сервера? Как много сервисов у вас стартует в виртуальной машине, чтобы была заметна разница?
Ах, очень сложный код sysVinit скрипта ZooKeeper. Сколько, в %, сложных стартап скриптов, если взять все использованные на всех ваших машинах, реальных, виртуальных и контейнерах? Вероятно, 1-2 на 10000 рабочих?
Predictable Network Interface Names — чУдная штука. Сколько раз в своей жизни вы меняли сетевую карту на сервере, причём на другую, чтобы это было реально нужно? А теперь сравните с количеством машин с одной сетевой картой — но имя её просто так не узнать…
Конечно же, это всё можно обойти и отключить.
Это всё можно выучить и использовать.
Вот только вместо логичной, с моей точки зрения, ситуации — когда сложные вещи приходится изучать людям, решающим сложные задачи — со всем этим приходится мириться вообще всем.grossws
06.04.2017 21:52+1Скажите, вы пробовали поддерживать init-скрипты хотя бы под два дистрибутива двух последних версий? Если да, то вопросов чем удобен systemd бы не возникало.
pkuutn
07.04.2017 11:44Именно об этом я и пишу. Что значит «поддерживать init скрипты»?
У вас есть задачи, которые требуют самописных скриптов?
Я, к примеру, в основном использую пакеты из дистрибутива, и они покрывают 99% моих потребностей.
И очень я сильно подозреваю, что и 99% ваших тоже.grossws
07.04.2017 12:37+1Именно об этом я и пишу. Что значит «поддерживать init скрипты»?
Поддерживать в актуальном и работоспособном состоянии. Или вы думали, что в пакеты они с неба упали? Эти init скрипты меняются со временем, в том числе от major версии к major версии как дистрибутива, так и запускаемой софтины. И они меняются от дистрибутива к дистрибутиву.
Этот геморрой ложится либо на мейтейнеров дистрибутива (если речь о популярном софте), или на разработчика софта (который тогда ограничивается корявым init-скриптом под свой дистрибутив, как правило). Иногда community допиливает эти скрипты где-нибудь в вики проекта до разумного состояния, но так случается не всегда.
У вас есть задачи, которые требуют самописных скриптов?
Я, к примеру, в основном использую пакеты из дистрибутива, и они покрывают 99% моих потребностей.
И очень я сильно подозреваю, что и 99% ваших тоже.А я не только использую софт из дистрибутива, я ещё и пишу его. И у меня порядка 10 актуальных конфигов под upstart (более 100 за время работы с ним) и ~50 unit'ов. Tell me all about it.
Shaz
06.04.2017 23:21А что по вашему простая задача? И если она простая — то в чем сложность ее решения?
VolCh
07.04.2017 10:02Простая задача была — запустить процесс при старте системы. Достаточно было чуть ли не симлинк на исполняемый файл сделать и всё. Что с systemd надо?
develop7
07.04.2017 10:41+2дада, "4 runlevelа будет достаточно для всех"
запустить процесс при старте системы
а это когда?
Достаточно было чуть ли не симлинк на исполняемый файл сделать и всё.
всё-таки не симлинк. особенно пикантно это заявление выглядит на фоне того факта, что
systemctl enable/disableсоздаёт/удаляет именно симлинки на юнитыVolCh
07.04.2017 11:56-2а это когда?
Когда всё из дистра уже запущено
всё-таки не симлинк
я написал "чуть ли не" :)
именно симлинки на юниты
Который сначала написать надо
develop7
07.04.2017 12:58+1Когда всё из дистра уже запущено
до запуска иксов или нет? А ждать монтирования /srv надо или нет?
Который сначала написать надо
батники тоже написать надо
VolCh
07.04.2017 15:47Я писал для машин, где иксов вообще нет. И к монтированию было ортогонально.
Написание "батников" — вещь, которой занимаешься постоянно для самых разных задач, особой специфики у init-скриптов нет. Юниты systemd хорошо (в плане обновления памяти) если раз в несколько месяцев надо писать.
За большую гибкость и возможность решать сложные задачи с помощью systemd приходится платить усложнением решения простых.
grossws
07.04.2017 15:56+1Напишите решение простой задачи, запуск недемонизирующегося процесса, который запускается после того как запустился, например, dnsmasq и требующего, чтобы он был запущен. Запускаться должно в runlevel 3/5.
В случае systemd выглядит следующим образом:
[Unit] Description=dnsmasq-dependent service After=dnsmasq.service Requires=dnsmasq.service [Service] ExecStart=/path/to/service [Install] WantedBy=multi-user.target
Для CentOS/RHEL и для Debian-based. Это же простая задача.
VolCh
07.04.2017 16:08-1Это задача гораздо более сложная, чем мне, как разработчику, приходится решать.
Shaz
07.04.2017 17:02+2Если 3 секции и 5 строк это гораздо сложнее ваших задач, то 2 вопроса:
Что вы делаете?
Что вас не устраивает?VolCh
07.04.2017 17:41-1Есть демон типа прокси: слушает один порт и делает запросы на другой. Нужно сделать его автозапуск от рута на обычном сервере с Ubuntu
Не устраивает, что скоро, похоже, для этого придётся писать гораздо больше чем init-скрипт на баше.
ValdikSS
08.04.2017 12:47+5Серьезно?!
В случае с sysvinit, вам нужно:
- Написать, как минимум, start и stop
- Вручную проверять статус сервиса
- Думать, в файл по какому пути записать PID процесса
Когда с systemd можно запустить демон одной командой:systemd-run, и даже unit писать не придется — можно просто скопировать сгенерированный.
ValdikSS
08.04.2017 12:43+4Вы просто не сталкивались с задачами, которые решает systemd, и кому они порядком надоели.
systemd — просто очень яркий пример. К примеру, одно из преимуществ systemd — параллельная загрузка, уменьшает время старта системы. Какому количеству пользователей это полезно? Как часто вы перезагружаете свои железные сервера? Как много сервисов у вас стартует в виртуальной машине, чтобы была заметна разница?
О, во времена sysvinit, когда был какой-то сервис, требовавший рабочее соединение с интернетом для запуска, включение компьютера без интернета приводило к задержке загрузки на 30 секунд и более, т.к. скрипт ждал появления сети.
Когда отлаживаешь падения ядра на компьютере, и каждый раз приходится ждать дополнительные 30 секунд, хочется забыть компьютеры и идти работать дворником.
Ах, очень сложный код sysVinit скрипта ZooKeeper. Сколько, в %, сложных стартап скриптов, если взять все использованные на всех ваших машинах, реальных, виртуальных и контейнерах? Вероятно, 1-2 на 10000 рабочих?
Очень много. Очень многие sysvinit-скрипты были сложными: в них проверялось наличие файлов, наличие других запущенных процессов, чего-то еще. Проверялсяstart-stop-daemon, ведь в некоторых дистрибутивах он отсутствовал или назывался иначе, из-за чего приходилось вставлять проверки прямо в скрипт.
Predictable Network Interface Names — чУдная штука. Сколько раз в своей жизни вы меняли сетевую карту на сервере, причём на другую, чтобы это было реально нужно? А теперь сравните с количеством машин с одной сетевой картой — но имя её просто так не узнать…
Видите, вы никогда не вставляли сетевые адаптеры или Wi-Fi-карты в USB. Вставив адаптер в конкретный порт, я знаю его имя, и знаю, что оно никогда не изменится. Без Predictable Network Interface Names получалось так, что компьютер, запущенный со вставленной картой в USB-слот, мог присвоить wlan0 внешней Wi-Fi-карте, а внутренней — wlan1, и все соединения, привязанные на wlan0, ломались. Или, например, сменив MAC-адрес на внутренней карте или включив его рандомизацию, включение компьютера оборачивалось только одним интерфейсом wlan2, без wlan0 и wlan1.
С Predictable Network Interface Names такого никогда не происходит.
grumbler66rus
11.04.2017 17:13GNU/Linux используется далеко не только на серверах. Число рабочих станций постепенно увеличивается, и там быстрая загрузка — большой плюс.
linux_art
11.04.2017 21:27+2Число рабочих станций с линуксом на фоне количества серверов с линуксом — капля в море.
selivanov_pavel
07.04.2017 00:21я долгое время был в лагере «systemd отстой», пока не начал изучать, что реально позволяет делать systemd
systemd безусловно решает проблемы, долгое время присутствовавшие в SysV. Но в обмен на решение этих проблем он добавляет в систему слишком много излишней сложности, что ИМХО вообще является расстрельным преступлением. Тот же upstart решал большую часть этих проблем, не превращаясь в переусложнённый мегакомбайн.
grossws
07.04.2017 00:42+1Расскажите, пожалуйста, как с upstart'ом решить простую проблему. Есть сервис S, который для работы требует запущенных X и Y.
Необходимо чтобы:
- сервис S стартовал при автозагрузке после того, как стартовали X и Y;
- сервис S останавливался при остановке любого из сервисов X и Y;
- сервис S запускался обратно, когда оба сервиса X и Y запущены (как пример, сделали
restart X).
В systemd это решается наличием 4 строк.
selivanov_pavel
07.04.2017 01:08По-моему как-то так:
/etc/init/S:
start on (started X and started Y) stop on (stopping X or stopping Y)
upstart далеко не идеален, я его привёл как пример, что для решения этих проблем не надо писать такого монстра.
grossws
07.04.2017 01:09Думаете, я просто так написал третий пункт? ,)
selivanov_pavel
07.04.2017 01:15А разве
start on (started X and started Y)его не обеспечит? Ведь после перезапуска X как раз такое состояние и наступит. Сейчас уже лениво, завтра надо будет покопатьсяgrossws
07.04.2017 01:19+1Нет, т. к. при перезапуске X прилетит только событие started X, а started Y не прилетит. Возможно, они это смогли починить какими-нибудь костылями, но когда крайний раз смотрел — не работало.
Есть довольно замысловатый вариант через промежуточный сервис, который будет проверять, что X и Y запущены, и посылать кастомное событие, от которого зависит S. Такой сервис-прослойка подписывается на
started X or started Y. Но это лютые убогие костыли.selivanov_pavel
07.04.2017 13:42-2Потыкал палочкой, у upstart всё действительно плохо :(
Но я не про то, что upstart хороший. Я про то, что теперь у нас init кроме запуска и сопровождения процессов занимается также: конфигурацией сети, настройкой локали, синхронизацией времени, хранением и обработкой логов, разрешением имён DNS, пляшет, поёт, вышивает крестиком… И всё это может ломаться в неожиданных местах или требовать странного: то /usr отдельно нельзя, то каталог для /var/log/journal теперь должен поддерживать posix acl, то юниты не могут быть симлинками, а должны быть обычными файлами, то нижний брейк станцевать требует...
iborzenkov
07.04.2017 13:54+3Блин, ну теперь палочкой потыкайте systemd, он не обидется.
init не занимается конфигурацией сети, настройкой локали, синхронизацией времени, логами, dns.
этим занимаются
NetworkManager
systemd-journald
systemd-resolved (на который кстати та же убунта перешла только в 17.04)
systemd-timesyncd
это все отдельные процессы, которые могут быть заменены
и у всего этого гораздо меньше неожиданных мест чем у sysvinit
разумеется не идеально, но уж точно лучше sysvinit и upstart с которыми сравниваютgrossws
07.04.2017 14:13+1Ещё systemd-networkd. И никто не запрещает не собирать или не использовать эти куски. Они opt-in, кроме systemd-journald и, кажется, systemd-logind. Первый обычно настроен на форвардинг логов в rsyslog/syslog-ng.
Тот же timesyncd куда более легковесный и простой в сравнении с классическим ntpd (который не только клиент, но и ntp server). Полезно вспомнить про ntp amplification attack, которые происходили довольно часто и без особых проблем именно благодаря существенно большей поверхности атаки ntpd и той легкости, с которой его можно сконфигурировать неправильно.
linux_art
11.04.2017 21:31А расскажите как мне собрать udev без systemd? :) В gentoo например это делается костыльно — собирается весь systemd и из собранного дерева вычленяется udev :)
grossws
11.04.2017 22:17tar xzf v233.tar.gz cd systemd-233/ ./autogen.sh ./configure # required to generate headers from txt files make src/basic/{arphrd,af,cap,errno}-{from,to}-name.h src/journal/audit_type-{from,to}-name.h src/udev/keyboard-keys-from-name.h # actual build make systemd-udevd udevadm -j4grossws
11.04.2017 22:43+1Как мне подсказали в багтрекере systemd, можно использовать
make built-sources systemd-udevd udevadm -j4. Autotools known issue.
Вполне вероятно, что мейнтейнерам gentoo было просто проще собрать целиком вместо того, чтобы перечислять нужные цели руками. Не столь уж долго оно собирается.
alexpolevoy
07.04.2017 18:18+2systemd так-то модульный. И да, что такого плохого в ACL для логов?
selivanov_pavel
07.04.2017 21:28То, что раньше это было сугубо опциональным, а теперь обязательно.
Во-первых, не всем это подходит: может там ФС какая-нибудь хитрая, может какие-нибудь хитрые программы с ACL плохо дружат. Это базовый компонент, он должен работать всюду и в любой возможной конфигурации ОС, а конфигурация без поддержки ACL вполне возможна, это штука не обязательная.
Во-вторых, обновляем ОС на следующий релиз и внезапно что-то ломается там, где раньше работало.alexpolevoy
07.04.2017 22:05А зачем использовать кастрированные ФС? Вроде уже не каменный век, выбор есть. А программы, не дружащие с ACL, не должны использоваться в продакшне вообще. Как по мне, безопасность важнее, особенно в наши дни, когда даже деньги не так важны, как данные. Да и деньги понемногу становятся данными, если уж на то пошло.
selivanov_pavel
07.04.2017 23:15-2А зачем использовать кастрированные ФС?
А программы, не дружащие с ACL, не должны использоваться в продакшне вообще.Мало ли какие задачи бывают. Мир не идеален, иногда приходится использовать что-то кривое, за отсутствием полностью удовлетворяющих задаче и имеющимся ресурсам прямых решений.
POSIX ACL(кстати, в стандарт они не включены, не обманывайтесь названием) — штука опциональная. Такие низкоуровневые системные службы, как init и логгер, должны работать не зависимо от включения/выключения опциональных возможностей. Ну то есть если завтра выйдет очередной релиз ядра и Линус объявит, что начиная с этого релиза ФС без поддержки ACL перестают монтироваться — тогда можно начинать писать системный софт, который на ACL завязан.
grossws
08.04.2017 02:23+1tmpfs, куда логи пишутся по умолчанию (при форвардинге в syslog) acl поддерживает, ext2/ext3/ext4, xfs, reiserfs, jfs, btrfs, hfs+, jffs2, nfs2/nfs3/nfs4, samba, ceph, gluster — тоже поддерживают. На чём вы собираетесь держать корневую fs, если вас так беспокоит это беспокоит? Может на fat32 или ntfs? Или вы специально отключаете поддержку acl при конфигурировании ядра?
alexpolevoy
08.04.2017 16:08POSIX ACL(кстати, в стандарт они не включены, не обманывайтесь названием) — штука опциональная
А тут дело в безопасносте и удобстве для админа.
Ну то есть если завтра выйдет очередной релиз ядра и Линус объявит, что начиная с этого релиза ФС без поддержки ACL перестают монтироваться — тогда можно начинать писать системный софт, который на ACL завязан.
А причём тут это? Покуда FAT32 остаётся актуальной, этого никто не сделает. Но что мешает не использовать её под системные вещи? Нужна простая ФС на раздел небольшого объёма? Есть нежурналируемая ext2. Для линуксов — нативнее некуда, её поддержка ничего не стоит, если стоит вопрос радикальной минимизации размера ядра. Её и в винде можно просматривать. Вообще, не могу представить кейс, при котором система должна быть размещена на ФС без поддержки ACL.selivanov_pavel
08.04.2017 16:19не могу представить кейс, при котором система должна быть размещена на ФС без поддержки ACL
NFS. ACL там есть, но это не POSIX, а свои, не совсем совместимые с POSIX ACL.
Вопрос не в том, может или нет кто-то представить такой кейс. Вопрос в том, что если стандарт допускает два варианта работы, то системный софт должен поддерживать оба варианта.
develop7
09.04.2017 11:58+1системный софт должен поддерживать оба варианта
Не должен. Уж точно не потому, что вы говорите так, будто вы эту функциональность оплатили.
selivanov_pavel
09.04.2017 17:03Эм… а я обязательно должен оплачивать разработку любого ПО, про которое хочу высказать своё мнение? Оплата только полностью или частичная годится?
develop7
10.04.2017 00:19Да высказывайте на здоровье, законом ведь не запрещено. Мне лишь почему-то кажется, что вам лично ни один из контрибьюторов в systemd не должны ничего вообще. А уж если кушать не можете от требования ACL на разделе с логами, ну так пришлите патч или наймите того, кто пришлёт и протащит в апстрим. Заодно и станет понятно, насколько оно вам мешает на самом деле. Всё за свой счёт, да.
selivanov_pavel
10.04.2017 00:35+1Я где-то говорил, что мне лично кто-то что-то должен? Мы обсуждаем systemd, я сказал, что оно решает многие проблемы, но с архитектурной точки зрения мне не нравится.
"Вы говорите, что плитку здесь положили криво, и в дождь всё время образуются лужа. Но мне кажется, что вам лично никто из строителей не должен ничего вообще. А если уж кушать не можете от этой лужи, что почините сами или наймите тех, кто починит. Заодно и станет понятно, насколько оно вам мешает на самом деле. Всё за свой счёт, да."
develop7
13.04.2017 10:18+1Я где-то говорил, что мне лично кто-то что-то должен?
Здесь:
системный софт должен поддерживать оба варианта.
говорите вы, значит, по определению, и должен вам (в том числе)
Вы говорите, что плитку здесь положили криво
не надо, некорректных аналогий в этом посте и так предостаточно
selivanov_pavel
13.04.2017 13:17Нет, "должен" не обязательно значит "должен мне", это так же может означать "таковы предъявляемые требования". Например: "зимнее дизтопливо должно иметь температуру застывания не более -35 C".
Такой унылый срач^W обсуждение, давайте закончим уже?
alexpolevoy
09.04.2017 16:06NFS. ACL там есть, но это не POSIX, а свои, не совсем совместимые с POSIX ACL.
Можно создать враппер. Это, само собой, принесёт кучу головной (и не только) боли при реализации, но с этим станет можно жить. И ещё вопрос тогда остаётся: зачем NFS для хранения системных файлов?selivanov_pavel
09.04.2017 17:06зачем NFS для хранения системных файлов?
Ну, допустим, загружаемый по сети тонкий клиент с маленьким объёмом памяти.
Не суть дело важно, можем мы с вами придумать хороший юз-кейс или нет. Могут быть такие задачи, с которыми ни вы ни я пока не сталкивались, но там это требуется.
Shaz
09.04.2017 17:56И зачем тонкому клиенту NFS? Логи хранить? а на кой они фиг сдались?
selivanov_pavel
09.04.2017 18:00+1Нет, корень монтировать. Я видел такой вариант использования. Складывать логи на сервер тоже в принципе можно через NFS
Yeah
07.04.2017 14:33+1А насколько реально/правильно/эффективно использовать systemd для старта демонов? Имеется worker, который делает какую-то фоновую задачу и берет задачи из очереди (если это важно, написан на PHP). Сейчас используется supervisor. Особенно интересует вопрос запуска N копий одного и того же процесса. В supervisor решается так:
process_name = %(program_name)s-%(process_num)02d numprocs=10
А как быть в systemd?
grossws
07.04.2017 15:42+1template unit и
for ((i=0; i<10; i=i+1)); do systemctl enable --now worker@$i ; done
iborzenkov
07.04.2017 15:46+1Ну вполне реально использовать шаблоны — как пример /lib/systemd/system/getty@.service и соответственно getty@tty1.service
Вполне себе используется во fleet на coreos.
update: Я буду обновлять страницу перед написанием комментария :)
4144
09.04.2017 22:45-5Вы не написали основную проблему systemd — нестабильность.
Если по какой-то причине любая часть systemd заглючит, с большой вероятностью init процесс будет работать некорректно или упадет. если упадет init, то упадут все процессы.
Т.к. systemd лепит почти все функции в init процесс. Тоже самое с безопасностью, т.к. все части обращаются к init процессу, его могут поломать.
Еще люди пишут что при загрузке какой-то юнит может повиснуть, и значит все система уже не загрузится. Либо если какой-то юнит упадет при загрузке, будет непонятно что. Но это думаю уже зависит от криво настроенных зависимостей.
В классических init системах, init процесс запускает что-то и более ничего не делает.
Или еще одна проблема из-за systemd, теперь много софта собирается с поддержкой systemd, и не может без него работать.
На пример если взять debian, чтобы записать cd через графическое приложение, systemd обязателен. Но какое отношение systemd имеет к записи cd? Права? так можно было сослаться что нет прав на устройство.
Еще одна проблема systemd монолитность. Он включает в себе и заменяет почти все что можно. есть веб сервер, сканер штрих кодов, dns сервер и т.д. эти части сильно завязаны друг на друга, и у вас нет возможности заменить какую-то из частей systemd на альтернативы.
Другая проблема, не знаю может её уже исправили. Если при загрузке включить лог ядра, то systemd зависает или падает.grossws
10.04.2017 02:38+2Извините, вы умственно полноценны? Если да, то почему не смогли прочитать разжеванные ответы на ваши "вопросы" выше в комментариях?
Вы не написали основную проблему systemd — нестабильность.
Если по какой-то причине любая часть systemd заглючит, с большой вероятностью init процесс будет работать некорректно или упадет. если упадет init, то упадут все процессы.
Т.к. systemd лепит почти все функции в init процесс. Тоже самое с безопасностью, т.к. все части обращаются к init процессу, его могут поломать.Пруфы? В частности про:
- "любая часть systemd заглючит, с большой вероятностью init процесс будет работать некорректно или упадет";
- "systemd лепит почти все функции в init процесс";
в классических init системах, init процесс запускает что-то и более ничего не делает
Как минимум, любой современный init (его pid1 часть) должен настроить консоль, свои файловые дескрипторы, стать session leader'ом, настроить свой coredump, настроить логгирование, поддерживать переход из initrd в нормальное окружение (то, что у systemd называется deserialize), загрузить LSM (selinux/apparmor/smack), настроить siganl handler'ы, запустить базовые процессы (в случае sysvinit — из
/etc/inittab, всякие getty и прочие радости) и следить за детьми и сигналами. Это на примере обычного sysvinit. Часто ещё надо смонтировать/proc, как минимум.
Так нелюбимый вами systemd делает примерно тоже. В дополнение он отключает часть инициализации, если работает в контейнере; монтирует
/dev,/proc,/sysи/sys/kernel/security; выполняет начальную настройку таймеров, инициализирует watchdog; настраивает cgroups, пишет в/run/systemd/containerидентификатор контейнера; устанавливает hostname из/etc/hostname; инициализирует интерфейсloи запускает управление сервисами, которое, конечно, внушительно по размеру (4k строк), но не огромное. Стоит помнить, что в sysvinit просто не даёт почти ничего из того, что умеет systemd в смысле управления сервисами.
На этом страхи и ужасы systemd заканчиваются, т. к. дальней работой занимаются небольшие изолированные сервисы (hostnamed, timedated, localed, logind, resolved, networkd). В случае же sysvinit обычно после этого запускает баш-скрипт (условный
/etc/init.d/rc), который запускает остальные сервисы, настраивает сеть, синхронизирует дату и время, устанавливает hwclock, настраивает локаль, создаёт устройства в /dev (благо у нормальных людей этим занимается devtmpfs, udev или mdev в случае busybox'а), настраивает hostname, настраивает клавиатуру, загружает модули. И, скорее всего, я много чего ещё не вспомнил сходу.
веб сервер, сканер штрих кодов, dns сервер и т.д. эти части сильно завязаны друг на друга, и у вас нет возможности заменить какую-то из частей systemd на альтернативы.
Вы с systemd исключительно по низкопробным агиткам знакомы? libqrencode, от которого зависит одна из почти сотни столь монолитных утилит из комплекта systemd используется для генерации qr-кода, чтобы дать пользователю удобное машиночитаемое представление сгенерированного приватного ключа, который после этого можно перенести с помощью камеры. DNS-сервер и DNS-ресолвер — это разные вещи, если что. И да, его можно не собирать. Минимальная сборка systemd включает в себя собственно systemd, journald и udevd (если его пока не отпилили обратно, вроде, собирались).
Вы ещё забыли про NTP-сервер, который на деле является SNTP-клиентом (Simple NTP, если что) против используемых стандартно ntpd/chronyd, которые являются настоящими тяжелыми ntp-серверами. И который, естественно для всех кроме хейтеров, можно не собирать и/или не паковать, если не надо.
grumbler66rus
11.04.2017 17:26У systemd помимо бинарных логов, которые сложно разбирать вручную, есть интересный недостаток по сравнению с SysVinit. В /etc/init.d/foobar я могу использовать свою команду, например, info, чтобы быстро получить существенную информацию от демона о его состоянии. В скрипте в case-ветке «info)» тривиально отфильтровать нужное из результата запроса к демону. В случае systemd свои команды непонятно как делать, приходится писать дополнительные скрипты сложности прежнего инит-скрипта. То есть делаем ту же работу, что и для SysVinit плюс работу для systemd.
Развейте мой заблуждение.grossws
11.04.2017 20:17systemd не запрещает делать свои команды, если нужна нестандартная/расширенная информация от конкретного сервиса: можно положить скрипт, дающий нужное представление. Но
systemctl statusдля этого не предназначен. Так в большинстве случаев было и при sysv, и при upstart'е.
См. также http://stackoverflow.com/a/39109294.
Yeah
А мне вот не понравилось в конфигах, что если я хочу кастомный конфиг для существующего сервиса, но при этом не хочу править дефолтный, то я должен обнулять запись. Примерно так:
/etc/systemd/system/docker.service.d:
Тупо как-то смотрится. Не говоря уж о том, что поведение неочевидное и мне пришлось гуглить это решение.
develop7
Ну да, corner case. Что не отменяет полезности концепции в общем.
pansa
Но зачем? «Родные» юниты сервисов, которые поставлены из пакетов, лежат в /usr/lib/system/.
Если вы хотите перекрыть их — положите модифицированный файл в /etc/systemd/system/ — и он будет иметь приоритет.
By Design же.
Yeah
Я специально привел имя файла, чтобы было видно, что я туда и положил, но пока не добавил эту пустую строку, докер упрямо запускался с сокетом.
rogoz
Нет, вы положили в /etc/systemd/system/docker.service.d/10-abcde.conf судя по вашему сообщению.
А надо, чтобы полностью перекрыть, класть в /etc/systemd/system/docker.service
snp
Соответствует документации, кстати говоря: