Pull to refresh

Comments 188

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


/etc/systemd/system/docker.service.d:


[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H 0.0.0.0:2375

Тупо как-то смотрится. Не говоря уж о том, что поведение неочевидное и мне пришлось гуглить это решение.

UFO just landed and posted this here
Но зачем? «Родные» юниты сервисов, которые поставлены из пакетов, лежат в /usr/lib/system/.
Если вы хотите перекрыть их — положите модифицированный файл в /etc/systemd/system/ — и он будет иметь приоритет.
By Design же.

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

Нет, вы положили в /etc/systemd/system/docker.service.d/10-abcde.conf судя по вашему сообщению.
А надо, чтобы полностью перекрыть, класть в /etc/systemd/system/docker.service

Соответствует документации, кстати говоря:


When Type= is not oneshot, only one command may and must be given.

If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect.

If more than one command is specified, the commands are invoked sequentially in the order they appear in the unit file.
Это ломает привычные инструменты, которые мы привыкли использовать для мониторинга системы: tail, cat, less и grep становятся бесполезны.

У меня вопрос по поводу бинарных логов.


Ведь стандартные команды типа "journalctl -u rsyslog.service" все равно могут предоставлять вывод в текстовом виде. По сути получается, что все претензии сводятся к тому, что не хочется в конвеере лишнюю команду добавлять.
Если раньше надо было
"less /var/log/service.log", то сейчас надо "journalctl -u service |less". Ну и с остальными командами нечто похожее.
я что-то не вижу большой разницы кроме того, что надо запоминть еще одну команду и ее ключ.


По сути вся информация на диске хранится в бинаром виде, вся разница лишь в том как ее предоставить в читабельном виде.

Если система не грузится даже в консоль (или если её грузить небезопасно по каким-то причинам), а хочется почитать логи для выяснения причины, как с какого-нибудь LiveCD почитать эти бинарные логи?

UFO just landed and posted this here

что я и говорил, надо просто запомнить еще одну программку.

Вместо простого универсального less нужно держать в голове ещё один аналог less и стопицот ключиков к нему для разных ситуаций :)
(Впрочем, я и не против, но блин, я уже несколько лет работаю с systemd, а ключики journalctl наизусть до сих пор не помню)

Вместо простого универсального less нужно держать в голове ещё один аналог less и стопицот ключиков к нему для разных ситуаций :)

Это совершенно естественная ситуация для специалиста. Надо выходить за свой предел и учить новые команды и ключи.


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


а ключики journalctl наизусть до сих пор не помню

миллионы людей работают с командой "ls", но не думаю, что они и половины ключей помнят. Знать все ключи восе необязательно :) Зря чтоли команду "man" придумали :)

в дебиане 8 с systemd из коробки по прежнему можно сделать less /var/log/foo.log

т. к. по умолчанию в debian (да и в rhel/centos) логи из journald перенаправляются в rsyslog/syslog-ng

по умолчанию в rsyslog/syslog-ng если быть точнее

Логи всегда читаются с помощью какой-то программки, например less. Технически никто не мешает авторам LiveCD положить рядом другую утилиту, например systemdlogless и можно пользоваться ей. Главное, чтобы пользователь знал про такую программу. Про ту же утилиту less человек узнает от других людей (посредством личной беседы или документации). Что мешает так же создать утилиту и распространять знания о ней?
Просто systemlog еще очень молод и не все выучили набор стандартных команд для работы с ним. Или еще не существует таких инструментов.


Поэтому бинарные логи — это не проблема systemd.

Не проблема до тех пор пока в силу какого-то сбоя не порушилась структура файла.

Как только systemd обнаруживает порчу лога, он закрывает его и начинает новый файл. Структура повреждённого лога восстанавливается в памяти при обращении к нему (сам файл в read-only), что даёт возможность обновлением systemd добавить новые алгоритмы восстановления для старых файлов. А если данные совсем потёрты-потеряны — то какая разница, вы их не прочитаете из бинарного лога или из текстового? :)

Из текстового можно вычленить хоть часть информации, а из бинарного в случае нарушения формата?

А утилитой strings из binutils воспользоваться? Про неё на каждом втором ответе в гугле про "как прочитать journal, если нет journalctl" написано. Потом можно грепнуть, например, по MESSAGE.

А еще можно забивать гвозди микроскопом…

Вам, извините, с битым файлом работать или просто поговорить? Напомню, что вы заявили проблемой "вычленить хоть часть информации".

Мне просто работать. А не заниматься нетрадиционными интимными отношениями с бинарными форматами и qr-кодами. Именно поэтому на моих серверах нету systemd и journald.

Если вам не приходится сталкиваться с проблемами, решение которых упрощает journald, то пользуйтесь старыми средствами, кто ж вам мешает?


При наличии journald, кстати, не возбраняется использовать их так же, как и раньше. Здесь в комментариях уже, кстати, не менее двух раз писали, что логи от сервисов прекрасно направляются в rsyslog/syslog-ng без каких-либо проблем. Достаточно не менять строчку ForwardToSyslog=yes в /etc/systemd/journald.conf.


При чём здесь qr-коды в контексте этого обсуждения — мне вообще не понятно. Никто не запрещает:


  • не собирать отображалку ключа для log sealing, а скопировать его руками (он просто отображается в консоли);
  • не использовать log sealing, т. е. не дёргать journalctl --setup-keys.
Как я уже писал выше, мне не нужно заниматься этим онанизмом с дополнительными прослойками. В моем дистрибутиве нету systemd по умолчанию и даже при этом я столкнулся с противоестественными решениями Поттеринга на тему именования сетевых устройств например. И вынужден был тратить свое время чтобы решить эту проблему, которая не возникла если бы RedHat и Поттеринг не пропихиливали это поделие в каждую щель.

Хотя persistent naming меня самого несколько раздражают (в частности, из-за поведения vmware и virtualbox), но откуда ноги растут — известно и понятно.


На машине с одним сетевым адаптером оно просто не проявляется и вполне можно прописать biosdevname=0 net.ifnames=0 в cmdline ядра один раз и забыть.


На машине же с несколькими (особенно одинаковыми) адаптерами и/или сетевыми адаптерами, подключенными по usb, — ад, который как раз и решается persistent naming.
Как и проблема замены адаптера на такой же, но с новым MACом, которая раньше была довольно неприятной.

Проблема в том что МНЕ это не надо, но У МЕНЯ нет выбора. Кому это надо — можно включить, но по умолчанию это не нужно. А сейчас все кому это не нужно, коих сильно больше чем имеющих специфичные конфигурации вынуждены иметь дело с этим идиотизмом.
но У МЕНЯ нет выбора

прописать biosdevname=0 net.ifnames=0 в cmdline

Вы уверены в том, что читали комментарий, на который отвечаете?


За сим, дискуссию завершаю.

Вы видимо тоже не особо читатель…
Кстати по поводу бинарных логов это вообще аргумент людей, которые «не читал но осуждаю»
В syslog systemd умел писать с самого начала, а сейчас вообще при установки syslog из пакетов он автоматически конфигурирует все что нужно в systemd. А с учетом того что syslog обычно устанавливается, то конфигурация с journal будет скорее всего только в контейнерах, для которых собственно он и отличный вариант
«less /var/log/service.log», то сейчас надо «journalctl -u service |less»

Вы же понимаете, чем отличаются выражения
less log.txt

и
cat log.txt | less


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

Systemd кому-то хорош, кому-то плох, но этот холивар не разрастался бы до таких масштабов, если бы была возможность в системе выбирать, что юзеру больше нравится. Сегодня же имеет ситуацию, что многие дистрибутивы весело и безальтернативно перешли на systemd, так что людям, которым старый подход ближе, остается только либо кухарить в стиле without-systemd.org, либо переходить на что-то вроде devuan. Конечно, такие «альтернативы» не всем по душе, хотя ведь разговор сводится к личному выбору каждого.
как вы думаете, какой вариант будет адекватнее к системным ресурсам?

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


Любая инфрмация с жесткого диска считывается какой-то программой. Не важно как информация хранится на диске, важно, чтобы пользователю эта информация предоставлялась в удобном для восприятия виде, были инструменты для обработки этой информации и эта программа была всегда доступна. У чисто текстового формата одно приемущество: для работы с ним придумано множество инструментов (ввиду простоты этого формата) и многие о них знают и пользуются для других задач.


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

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


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


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

Любая инфрмация с жесткого диска считывается какой-то программой

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

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

Прогресс же… «Здоровый прогресс необходим, но если оно и так работало — зачем менять?» Это заявление и ваше «Здоровый консерватизм, конечно, нужен, но не в ущерб прогрессу» одинаково имеют право на существование. А получаем очередную революцию, когда пришли большевики, и сказали, что отныне будем жить по-другому.

Если каждый будет выбирать, то будет еще хуже.

Зря вы так. Кому хуже? Почему вы решили, что выбор безальтернативный — самый лучший?

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


одинаково имеют право на существование.

Право то имеют, только одна идея поддерживает прогресс, а другая регресс т.к. идие противоположные.
Поэтому одна идея ложная другая нет. Если развитие linux внедрение systemd не повредит, то значит правильно был сделан выбор в пользу systemd. Но это только время покажет.


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

Так и получилось. Кому не нравятся пусть садятся на свой пароход и плывут в сторону "devuan", благо у нас опенсорс.


Почему вы решили, что выбор безальтернативный — самый лучший?

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


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


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


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

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

Кстати о windows.
Тот же windows8 был принят в штыки. Но ничего, Mirosoft немного подшаманил и windows10 уже был принят более благосклонно и вроде бы неплохо продается. Т.е. свои задачи выполняет.


А критика windows10 примерно такого же уровня как и systemd.

Это тот Windows 10, про который только ленивый не пошутил «нет я не хочу обновиться»?
Ох уж мне эти «прогресс не остановить» граждане!

Вы еще скажите, что, раз новая версия ОС вышла, старые по всему миру нужно срочно снести и удалить. А заодно сжечь компы, на которых старые ОС эти установлены. А то нефиг — уже вышли новые компы, но эти новые компы и сервера (прогрессивные донельзя) никто не покупает!

Да что компы?! Я вот на улице каждый день вижу сотни и сотни не совсем новых машин. Даром, что машина 20 летней давности покрепче свежевыпущенной будет, даром, что свежие гниют (после взгляда на их металл) куда легче — менять (!!!), и никаких тут. Отобрать у владельцев, и пусть покупают себе новые! Конечно, за новые свои деньги — как раз и рынок застоя избежит.

Плохо, конечно, что сервера эти иногда стоят для дела, а не только для постоянного обновления. Но тут, конечно, тактика большевиков поможет: «кто не все — того накажем», прогрессом!

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

Возвращаясь к вашей аналогии, я бы сказал, что зачем против хорошо привычной схемы с init.d придумывать еще что-то, на что потратятся силы девелоперов? Люди годами (десятилетиями!) пишут привычные скрипты запуска, на всякую проблему уже куча костылей и решений придумано — оно работает, зачем ломать и вообще распылять силы сообщества? Вы что, скажете, разработчикам нечем заняться, кроме как переводить свои пакеты на новую систему (причем я её тут даже не пишу — через несколько лет, поверьте, придет новый «мессия.d», и про него все будут говорить точно то же, что уж он-то точно всех подружит.

Если развитие linux внедрение systemd не повредит, то значит правильно был сделан выбор в пользу systemd

Вы знаете, было бы правильнее сказать, что раз уж даже такое странное дело, как внедрение systemd, не развалило экосистему (хотя части людей и части серверов жить стало хуже), то идеи Unix показали свою глубинность и выдержали проверку не только временем, но и глупо великими новыми мыслями.
Ох уж мне эти «прогресс не остановить» граждане!

Есть объективные законы развития, нравятся вам они или нет.
Человечество с момента своего возникновения развивает свои средства производства. И все время будут появляться более сложные вещи. Надо к этому привыкнуть.


Вы еще скажите, что, раз новая версия ОС вышла, старые по всему миру нужно срочно снести и удалить.

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


Для меня лично, многие новые вещи тоже кажутся слишком преусложненными т.к. мои потребности удовлетоворяют вещи созданые 10-20 лет назад. Сейчас свобода, хочешь пользуйся новинками, хочешь не пользуйся. По большому счету никто не заставяет. Но не надо пытаться остановить паровоз прогресса.


Но тут, конечно, тактика большевиков поможет: «кто не все — того накажем», прогрессом!

Если я правильно понимаю, вы о большивиках знаете только из перестроечных агито :)


Возвращаясь к вашей аналогии, я бы сказал, что зачем против хорошо привычной схемы с init.d придумывать еще что-то, на что потратятся силы девелоперов?

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


Systemd тоже не конец истории возможно лет через 30 ему что-то придет на смену, когда всем надоест писать для него костыли.


не развалило экосистему

Внедрение одного стандарта как раз сплачивает систему. И люди как раз показали силу прогресса.
Стандартизация и унификация как раз характерная черта развития.
Они смогли объединить силы для развития одного продукта. Да, не идеального, но уже одного на всех.

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

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

Внедрение одного стандарта как раз сплачивает систему.


Неверно говорите. Напишите «еще одного стандарта», потому что, худо-бедно, стандартов хватало и до systemd, и хватит после.

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

Тем более что «до основания, а затем» менять все, как кажется, не стоило. Ну, стали логи в бинарном формате хранить (хотя могли в текстовом виде) — экономия места на этом не скомпенсировала разрастание числа и объема фалов с котиками в интернетах, а вот сложность добавила. Но даже бинарные логи (я про новую идеологию в systemd, без скидывания логов в текстовые файлы) просматривать стало-то неудобнее.

Серьезно, я бы ожидал, что для новой системы запуска будет как-то логично хранить и вызывать логи запуска отдельных сервисов понятнее, чем раньше (ибо логи смотрятся очень часто). Запускаю софтину, «что-то пошло не так» — покажите мне простой командой логи последнего запуска же! Ан нет, мне пишут, натурально, что «что-то пошло не так, напишите вот такую команду с вот такими ключами» (существенно неудобную к написанию конструкцию — а она нужна часто), которая покажет не лог последнего запуска, а
несколько
(и выбирая по числу, а не по логике запуска) последних строк из общего лога, где мне нужные строки могут быть, а могут и нет. Работа с логом в этой ситуации напоминает ремонт двигателя автомобиля через выхлопную трубу.

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

Я лично, признаться, жду, когда появится приемник systemd. Год-два, конечно, это займет (не 20-30 лет), но этом systemd-ng,  будем надеяться, могут быть решены некоторые вещи.

Но, повторю, когда мне насильственно и безальтернативно ставят внутрь машины новую столь важную систему, это несколько «широко» получается. Ну, понятно, что надо было что-то отвечать MS, когда последние выкорчевали меню «Пуск» в 8-ке, но все же — выбор-то должен быть!
Вы уж определитесь, мы про свободу и выбор, или про насильственное (точнее, безальтернативное — что важнее) внедрение нового везде

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


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


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


Поэтому с одной стороны у вас есть выбор, а с другой нет. И так везде.


Ну, стали логи в бинарном формате хранить

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


Ан нет, мне пишут, натурально, что «что-то пошло не так, напишите вот такую команду с вот такими ключами»

Это просто брюзжание. Вам ведь надо узначть, что случилось. Напишите команду и узнаете в чем проблема. Несколько раз повторите, будете ее на память помнить как и less. Это лишь вопрос привычки.


У вас общий подход неверный. Когда мне надо разобраться с новой программой (установить, настроить, починить), для меня наоборот это интересно. Узнаю что-то новое, обновлю свой багаж. Если я запомню еще пяток команд мне это не повредит. Я же не еще один кирпич в сумке буду носит :)


но все же — выбор-то должен быть!

Используйте FreeBSD :)

Несколько раз повторите, будете ее на память помнить как и less. Это лишь вопрос привычки.

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

UFO just landed and posted this here
Используйте FreeBSD :)

Это лихо Вы! Это вы перечеркнули всю свою логику, и правильно!

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

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

Пока из важных изменений вижу только написание скриптов/юнитов/еще чего-то для запуска ПО в разных системах инициализации/управления. Но Вы и сами знаете, что писать их нужно довольно редко (грубо говоря — по разу каждый, а дальше как очень понадобится), так что большой нагрузки на мейнтейнера это не наложит. А вот нагрузку на тысячи специалистов и систем внедрение кардинально новой system-wide софтины наложит, и еще как.

В общем, революции (как говорят апологеты каждой) делаются не на пустом месте. Но цена каждого революционного изменения бывает куда выше, чем эти апологеты считают. systemd — это не поворот сибирских рек, пользы от него не так много, конечно, но по аналогии, и вреда от его невведения было бы меньше.
UFO just landed and posted this here
Я вот, скажем, хочу или не хочу — но не особо меня спрашивают, ОС ставится с тем, что ее создателям в голову пришло положить. Да и вы, вот, от имени человечества, говорите, что, мол, нефиг шагать не в ногу, и что переход на шагание строевым шагом только в ногу — прямо естественный шаг, и что при Коммунизме на следующем этапе развития средств производства только так и будем ходить.

У вас всегда есть свобода собрать свой дистрибутив, если вас не устраивают существующие.


Мейнтейнеры вам ничем не обязаны. Они часто тратят своё личное время, и его экономия при использовании systemd'шных unit'ов является достаточно значительной, чтобы на него переехать.


Вон devuan'овцы (типа debian без systemd от "veteran unix admins") денег собирают с хейтеров, которым нужен debian с sysvinit, можете присоединиться к их инициативе. Возможно, получите debian jessie с заменой systemd на sysvinit. Если он, конечно, выйдет. То что-то они долго udev пересобирают и init-скрипты пишут.


Что-то когда ck2 подыхал в муках, никто не пришел его спасать. Ни деньгами, ни вложением своих сил в его починку и развитие. Зато на заменивший его logind воплей выше крыши (в стиле "ааа, наш gnome3 зависит от systemd").

Но даже бинарные логи (я про новую идеологию в 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 строк из лога.
IMHO вся разница заключается исключительно в том, что в первом случае у нас один процесс, во втором — два процесса.
Так как у нас пайп, то информация нигде в промежуточном виде не хранится — считывается поблочно и передается сразу. Пока не может передаваться — не считывается.
Разработчик или майнтейнер?
И да, когда старое прекрасно работало, а новое не дает никаких преимуществ это раздражает. Тянуть к прогрессу за уши плохая идея, нужно показывать преимущества чтобы пользователь пришел самостоятельно.
UFO just landed and posted this here
Без обид но.
1. Ровно тождественно скриптам в init.d
2. Есть различные runit, daemontools и прочие супевизоры
3. Не нужно. Не то место чтобы чего то крутить. Стартовали — запустили. Все — миссия исполнена.
  1. Что в слове пользовательские вам показалось непонятным? Пользовательские лежат не в /etc/systemd/system//usr/lib/systemd/system, а в $XDG_CONFIG/systemd/usr.
  2. Умеют ли они в cgroups и/или другие способы отслеживания всех потомков процесса на эффективно неограниченную глубину (про "умеют ли в зависимости" даже не спрашиваю)?
  3. Если у вас сервисы настолько тривиальны, что вам это не нужно, используйте runit. Хотя, наличие этих ручек не ухудшает UX.
1. Мне как раз все понятно. Пользовательские лежат в хоуме пользователя аналогично как это сделано у крона. init.d ничуть этому не мешает.
2. Умеют. Они для этого и созданы. Зависимости не их задача, их дело отследить и поднять упавшее.
3. Не ухудшает. Но преимуществом является далеко не всем.

Я же сразу написал «когда старое прекрасно работало, а новое не дает никаких преимуществ это раздражает». Когда нужно просто стартовать систему все эти выверты как правило не нужны. Даже параллельный старт, вещь по сути хорошая, особенной пользы не несет.
И вдруг внезапно предлагают — меняйте все, используйте это. Не дав никаких практических преимуществ кроме осознания приобщения к прогрессу.
Да нафик нормальному человеку этот прогресс, ему нужна стабильность и минимум телодвижений при обновлении.
Отсюда и весь негатив. Никто не против самого системд, весь срач за безальтернативность оного.
> Пользовательские лежат в хоуме пользователя аналогично как это сделано у крона.

Правда что ли? Давно ли у крона они переехали из /var/spool/crontab/USERNAME к пользователю в дом? Смешно видеть, как человек не знающий элементарных вещей пытается критиковать что-то серьезное.
У меня лет 10 как так сделано. Легким движением руки что характерно.
Т.е. вы просто не знаете как это сделать и смеётесь над теми кто знает?
UFO just landed and posted this here
> На первый взгляд, то на то и получаем. Но, скажем, если лог у нас оказался реально большим (давайте добавим для усиления, что — большим, что размер ОЗУ), как вы думаете, какой вариант будет адекватнее к системным ресурсам?

И на второй взгляд тоже =)
Если вы намекаете, что во втором случае весь файл будет помещен в память — вы ошибаетесь. Проверить это не составит труда.

Но к пожарной безопасности это не имеет никакого отношения, как говорил Остап =) Systemd, при всех огрехах, безусловное добро.
Безусловное добро он только при одном условии — он хорошо ложится на ваш юз кейс. Все поделки Поттеринга отличаются этим свойством. Всем остальным же они ломают всё. Зависимости, годами работающие системы и т.д.

Если бы только одну команду запомнить. А надо то ещё запоминать названия всех сервисов. Раньше можно было набрать cat /var/log/a-few-letters и нажать tab либо вообще поставить звёздочку, а теперь надо запускать systemctl, где искать полное название сервиса и копипастить его в параметры journalctl. Или всё же есть адекватный способ?

UFO just landed and posted this here

Не так давно в арче какой то паленый systemd завезли, что автокомплит в фише вызывал приступы ненависти в связи с тормозами где то внутри системд. Когда status выполнялся по 10 секунд. Попытки гуглежа приводили к разросшимся логам, которые были немедленно зачищены, что лишь немного уменьшило задержки Плюнул и выкинул арч ибо не для меня он со своими вечносломаными обновами. Когда его (арч) ставил на свой рабочий системник, то нужно было развернуть здесь и сейчас, да побыстрее. Как такие приколы вообще могут попадать, пусть и в дистрибутив для теж кому сырое мясо по вкусу.

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


Для простых задач systemd отлично подходит, скопипастил файлик, подправил пути, названия и сервис готов.


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


А нудеть, что "мы не можем теперь смотреть логи с помощью less" — это детский сад.


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

UFO just landed and posted this here
UFO just landed and posted this here
Бинарные логи, кстати, тоже можно сделать относительно надёжными. Современные архиваторы умеют так делать. Стойкость, конечно, не стопроцентная, но после мелких повреждений вернуть к жизни тот же 7z или rar не составляет особого труда, если при его создании была заложена инфа для восстановления.
UFO just landed and posted this here
Аудио/видеокодекам это не мешает использоваться для стриминга, где и теряется, и не дописывается постоянно. Это критично уже для админа, которому потом разгребать последствия сбоя, но никак не для самого формата. Ну, и текст тоже может не записаться, от этого страховки тоже никакой. Система не успела сделать sync перед отключением питания — и всё, можно помахать ручкой хоть текстовым, хоть бинарным данным.

Если уж вы так сильно уповаете на системные логи — гораздо надёжнее настроить их пересылку на какой-нибудь централизованный сервер в syslog/rsyslog/systemd и там уже хранить их как душе угодно, благо systemd умеет это. И получится гораздо удобнее чем тем же rsyslog читать файлы с диска и через udp или tcp гнать их на другой сервер для хранения

UFO just landed and posted this here
А вот потеря логов — это пи!#$%ц!!! Задача логгера — НАДЕЖНО ЛОГИРОВАТЬ,

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


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


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


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


теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service.

Даже без systemd уже странно держать две системы инициализации. С третьей, конечно еще веселее.

UFO just landed and posted this here

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


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

А чего стоят идиотские названия устройств типа enp1s0 вместо обычного eth0? Появилось когда втащили UDEV в кодовую базу SystemD. Лечится естественно статичным переименованием, но зачем было ломать то что работало десятилетиями?
теперь у меня в системе болтается systemv, systemd и upstart в дикой мешанине с костылями через service. Уже или галстук, или трусы…

Это проблема вашего дистрибутива, а не systemd. А в прогрессивных дистрибутивах такой проблемы нет, они уже давно целиком перешли на systemd без костылей.

UFO just landed and posted this here
Вы это, обновляться пробовали?
ubuntu — 16.04
debian — с jessie
rhel — с 7
Дефолтными между прочем, разумеется сохранив совместимость с sysV и upstart для убунты.
Арч даже поддерживает и гента только не по дефолту.

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

Между "дефолтными" и "целиком" есть разница. Целиком подразумевается, что нет "совместимость с sysV и upstart для убунты"

Целиком вы подразумеваете что выпилят поддержку всего остального?
Так этого не будет, если есть система инициализации в дистрибутиве — ее будут поддерживать.
Вот когда похоронят upstart и sysV то тогда и выпилят. Ну а так уже отдельные новые пакеты не пишут скрипты для sysV оставляя только файл для systemd.
А, дико извиняюсь, посмотрел на свою ubuntu 17.04
sysvinit в репе отсутствуют — только утилиты остались
upstart есть, но дефолтным его можно поставить только ручками
ну конфиги будут подчищать потихоньку из пакетов
UFO just landed and posted this here
«теперь у меня в системе болтается 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

UFO just landed and posted this here
Бинарный формат — это не только скорость поиска\индексирование, это ещё и скорость записи. То что данная реализация так косячит — не является проблемой подхода. Естественно в главу угла при реализации логгера надо ставить надёжность.
UFO just landed and posted this here
Что у вас за файловая система, что логи systemd-journald повреждаются?
В прошлом году отлаживал падения и зависания ядра, очень долго и нудно, компьютер зависал минимум сто раз, и база не повреждалась. У меня ext4, в нем, как во всех современных файловых системах, есть механизм журналирования и транзакций. Если какой-то блок информации попытался записаться на диск, и в это время произошло что-то фатальное (упало ядро), то блок просто отбросится при попытке чтения и удалится при первом же fsck.
А мне не нравится только то, что он сидит на PID 1 и я его никак и ничем не могу контролировать и не могу его перезапустить. Конкретнее напрягает то, что он очень большой и слабопроверямый. Хорошо бы написать какой-нибудь простой враппер, который бы сидел на PID 1 и транслировал бы все сигналы и возвраты зомбей к запущенному им systemd, но который мог бы запускать также и доверенные, не подчиняющиеся systemd процессы.

он вроде бы как-бы замена стандартному init, который с самого начала сидел на PID=1


Конкретнее напрягает то, что он очень большой и слабопроверямый.

Любая программа такого уровня большая и сложнопроверяемая. Не думаю, что SystemV init сильно проще, он просто переносит часть сложность на разработчиков скриптов инициализации.

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

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

Вы только на LOR'е про systemd слышали? systemd-journald — это отдельный процесс, он не в PID1. Видели ли вы "вживую" падение systemd pid1 (given живая fs)?

Вы только на LOR'е про systemd слышали? systemd-journald — это отдельный процесс, он не в PID1.

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

а монстр «все в одном» — тупиковый путь развития. больше кода — больше ошибок, выше вероятность падения. не?

Видели ли вы «вживую» падение systemd pid1 (given живая fs)?

https://access.redhat.com/security/vulnerabilities/2679271 к примеру. тупейший баг, да.

и да, при мертвой (или ушедшей в рид-онли) ФС init тоже не должен падать. хотя бы потому, что в этот момент может быть живой шелл, через который сисадмин пытается диагностировать/пофиксить удаленно проблему. а после смерти инита из-за ФС — система просто не сможет забутиться.
а монстр «все в одном» — тупиковый путь развития. больше кода — больше ошибок, выше вероятность падения. не?

Оно, благо, модульное. Но многих хейтеров это не останавливает, и они начинают кричать, что 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 очень не понравилась в своё время. Благо, на ноуте, а не на сервере.

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

Но усложняет жизнь обычным пользователям. С init достаточно было знать азы bash, чтобы написать обвязку для своего демона, теперь же надо штудировать маны, разбираться в синтаксисе и флоу, при этом азы bash знать нужно всё равно.

UFO just landed and posted this here

Ключевая фраза "для своего". Что я могу скопипастить для демона, которого закончу писать через пару часов?

UFO just landed and posted this here

Несколько часов на демона и несколько часов на его systemd обвязку?

Вы пробовали? Или так, от балды "несколько часов на его systemd обвязку"? У меня первое написание unit'а заняло меньше 15 минут, благо в man'ом пользоваться умею.

Оценил объём текста по вашей ссылке. Причём, навскидку, нужно ознакомиться со всем девятым разделом, а не только 9.6, если хочется хотя бы минимально понимать как systemd работает.

Эту ссылку дал develop7, если что. Там объём текста на полчаса вдумчивого чтения. Включая краткую инструкцию по миграции init.d'шных скриптов в unit'ы, которая при написании нового — не актуальна.

А можно вообще ничего не писать, а запустить программу через systemd-run и использовать созданный им юнит.
UFO just landed and posted this here
UFO just landed and posted this here

И обычные пользователи типа, скажем Atlassian с этим откровенно не справлялись. Хотя азы баша они явно знают.


Ну и как разработчик, скажу, что мне systemd очень сильно упрощает жизнь. Как вспомню start-stop-daemon и подобное барахло, абсолютно невнятную систему зависимостей sysvinit'а и прочие подобные радости, так убивать хочется.

что не должно быть в init'е.

Вроде бы нет стандарта на то, чего не должно быть.
Поэтому авторы добавляют то, что считют нужным. Обычно это то, что всегда присутствует в системе.

В прежние времена мы использовали что-то вроде supervisord для отслеживания, что процессы работают.

[Service]
...
Restart=always
RestartSec=1

А в supervisord не тоже самое? Мы его, к слову, до сих пор используем.

[program:api]
autostart=true
autorestart=true
startretries=3

Ну так теперь это уже интегрировано в систему без дополнительных сервисов.

Когда supervisord научится использовать cgroups, тогда можно будет сравнивать.

Уважаемые гуру системд. Как грамотно запускать сервис после полной инициализации сети? Проблема в том, что сквид например через раз сокет нормально инициилизирует, потому что интерфейс поднялся, а адрес еще не назначен. Писать After=network-ready.service не помогает.
Cейчас под рукой нет линукса, но нужно писать что-то вроде After=network-online.service или там даже большие буквы есть, типа Network-online.service, нужно смотреть в папке с юнитами

man 7 systemd.special, см. network.target и network-online.target

А гарантированного способа нет, network-online.target ближайшее что есть. Рекомендуется писать сервисы так, чтоб они нормально понимали отсутствие сети.
Ну а у меня следующий вопрос. Имеется софтина, которая меняет правила iptables, сформированные shorewall-ом, при запуске и останове. Требуется, чтобы при перезапуске shorewall эта совтина останавливалась, ждала перезапуска shorewall, а потом снова запускалась. Как это можно реализовать в виде зависимостей?
Через группы сервисов.

Думаю, что-то такое (и, соответственно, старт/стоп/рестарт делать на 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
systemd-escape

может просто не надо писать баш-скрипты в systemd?
Т.е. я про то, почему это должно быть непременно частью something.service, а не частью например something.sh, который отробатывает в ExecStart...


IMHO systemd-escape сделана как helper, чтобы писать динамические systemd-скрипты (т.е. не руками, а "машинным" способом).

UFO just landed and posted this here
SystemD отстой, да здравствует 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.
С моей точки зрения, проблема заметно шире, чем systemd.
Она затрагивает большУю часть свободного ПО.
Вероятно, связана она с тем, что большинство программистов имеют довольно высокий интеллект.
И, соответственно, очень любят решать сложные задачи. А рутинные и несложные — не любят.
А в реальной эксплуатации сложные задачи и проблемы возникают редко.
Но мы получаем набор элегантных решений для сложных проблем — вместо вылизанных до блеска решений проблем рутинных.
systemd — просто очень яркий пример. К примеру, одно из преимуществ systemd — параллельная загрузка, уменьшает время старта системы. Какому количеству пользователей это полезно? Как часто вы перезагружаете свои железные сервера? Как много сервисов у вас стартует в виртуальной машине, чтобы была заметна разница?
Ах, очень сложный код sysVinit скрипта ZooKeeper. Сколько, в %, сложных стартап скриптов, если взять все использованные на всех ваших машинах, реальных, виртуальных и контейнерах? Вероятно, 1-2 на 10000 рабочих?
Predictable Network Interface Names — чУдная штука. Сколько раз в своей жизни вы меняли сетевую карту на сервере, причём на другую, чтобы это было реально нужно? А теперь сравните с количеством машин с одной сетевой картой — но имя её просто так не узнать…
Конечно же, это всё можно обойти и отключить.
Это всё можно выучить и использовать.
Вот только вместо логичной, с моей точки зрения, ситуации — когда сложные вещи приходится изучать людям, решающим сложные задачи — со всем этим приходится мириться вообще всем.

Скажите, вы пробовали поддерживать init-скрипты хотя бы под два дистрибутива двух последних версий? Если да, то вопросов чем удобен systemd бы не возникало.

Именно об этом я и пишу. Что значит «поддерживать init скрипты»?
У вас есть задачи, которые требуют самописных скриптов?
Я, к примеру, в основном использую пакеты из дистрибутива, и они покрывают 99% моих потребностей.
И очень я сильно подозреваю, что и 99% ваших тоже.
Именно об этом я и пишу. Что значит «поддерживать init скрипты»?

Поддерживать в актуальном и работоспособном состоянии. Или вы думали, что в пакеты они с неба упали? Эти init скрипты меняются со временем, в том числе от major версии к major версии как дистрибутива, так и запускаемой софтины. И они меняются от дистрибутива к дистрибутиву.


Этот геморрой ложится либо на мейтейнеров дистрибутива (если речь о популярном софте), или на разработчика софта (который тогда ограничивается корявым init-скриптом под свой дистрибутив, как правило). Иногда community допиливает эти скрипты где-нибудь в вики проекта до разумного состояния, но так случается не всегда.


У вас есть задачи, которые требуют самописных скриптов?
Я, к примеру, в основном использую пакеты из дистрибутива, и они покрывают 99% моих потребностей.
И очень я сильно подозреваю, что и 99% ваших тоже.

А я не только использую софт из дистрибутива, я ещё и пишу его. И у меня порядка 10 актуальных конфигов под upstart (более 100 за время работы с ним) и ~50 unit'ов. Tell me all about it.

А что по вашему простая задача? И если она простая — то в чем сложность ее решения?

Простая задача была — запустить процесс при старте системы. Достаточно было чуть ли не симлинк на исполняемый файл сделать и всё. Что с systemd надо?

UFO just landed and posted this here
а это когда?

Когда всё из дистра уже запущено


всё-таки не симлинк

я написал "чуть ли не" :)


именно симлинки на юниты

Который сначала написать надо

UFO just landed and posted this here

Я писал для машин, где иксов вообще нет. И к монтированию было ортогонально.


Написание "батников" — вещь, которой занимаешься постоянно для самых разных задач, особой специфики у init-скриптов нет. Юниты systemd хорошо (в плане обновления памяти) если раз в несколько месяцев надо писать.


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

Напишите решение простой задачи, запуск недемонизирующегося процесса, который запускается после того как запустился, например, 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. Это же простая задача.

Это задача гораздо более сложная, чем мне, как разработчику, приходится решать.

Если 3 секции и 5 строк это гораздо сложнее ваших задач, то 2 вопроса:
Что вы делаете?
Что вас не устраивает?

Есть демон типа прокси: слушает один порт и делает запросы на другой. Нужно сделать его автозапуск от рута на обычном сервере с Ubuntu


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

Серьезно?!
В случае с sysvinit, вам нужно:
  1. Написать, как минимум, start и stop
  2. Вручную проверять статус сервиса
  3. Думать, в файл по какому пути записать PID процесса

Когда с systemd можно запустить демон одной командой: systemd-run, и даже unit писать не придется — можно просто скопировать сгенерированный.
Вы просто не сталкивались с задачами, которые решает 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 такого никогда не происходит.
GNU/Linux используется далеко не только на серверах. Число рабочих станций постепенно увеличивается, и там быстрая загрузка — большой плюс.
Число рабочих станций с линуксом на фоне количества серверов с линуксом — капля в море.
я долгое время был в лагере «systemd отстой», пока не начал изучать, что реально позволяет делать systemd

systemd безусловно решает проблемы, долгое время присутствовавшие в SysV. Но в обмен на решение этих проблем он добавляет в систему слишком много излишней сложности, что ИМХО вообще является расстрельным преступлением. Тот же upstart решал большую часть этих проблем, не превращаясь в переусложнённый мегакомбайн.

Расскажите, пожалуйста, как с upstart'ом решить простую проблему. Есть сервис S, который для работы требует запущенных X и Y.


Необходимо чтобы:


  • сервис S стартовал при автозагрузке после того, как стартовали X и Y;
  • сервис S останавливался при остановке любого из сервисов X и Y;
  • сервис S запускался обратно, когда оба сервиса X и Y запущены (как пример, сделали restart X).

В systemd это решается наличием 4 строк.

По-моему как-то так:


/etc/init/S:


start on (started X and started Y)
stop on (stopping X or stopping Y)

upstart далеко не идеален, я его привёл как пример, что для решения этих проблем не надо писать такого монстра.

Думаете, я просто так написал третий пункт? ,)

А разве start on (started X and started Y) его не обеспечит? Ведь после перезапуска X как раз такое состояние и наступит. Сейчас уже лениво, завтра надо будет покопаться

Нет, т. к. при перезапуске X прилетит только событие started X, а started Y не прилетит. Возможно, они это смогли починить какими-нибудь костылями, но когда крайний раз смотрел — не работало.


Есть довольно замысловатый вариант через промежуточный сервис, который будет проверять, что X и Y запущены, и посылать кастомное событие, от которого зависит S. Такой сервис-прослойка подписывается на started X or started Y. Но это лютые убогие костыли.

Потыкал палочкой, у upstart всё действительно плохо :(


Но я не про то, что upstart хороший. Я про то, что теперь у нас init кроме запуска и сопровождения процессов занимается также: конфигурацией сети, настройкой локали, синхронизацией времени, хранением и обработкой логов, разрешением имён DNS, пляшет, поёт, вышивает крестиком… И всё это может ломаться в неожиданных местах или требовать странного: то /usr отдельно нельзя, то каталог для /var/log/journal теперь должен поддерживать posix acl, то юниты не могут быть симлинками, а должны быть обычными файлами, то нижний брейк станцевать требует...

Блин, ну теперь палочкой потыкайте systemd, он не обидется.
init не занимается конфигурацией сети, настройкой локали, синхронизацией времени, логами, dns.
этим занимаются
NetworkManager
systemd-journald
systemd-resolved (на который кстати та же убунта перешла только в 17.04)
systemd-timesyncd

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

Ещё systemd-networkd. И никто не запрещает не собирать или не использовать эти куски. Они opt-in, кроме systemd-journald и, кажется, systemd-logind. Первый обычно настроен на форвардинг логов в rsyslog/syslog-ng.


Тот же timesyncd куда более легковесный и простой в сравнении с классическим ntpd (который не только клиент, но и ntp server). Полезно вспомнить про ntp amplification attack, которые происходили довольно часто и без особых проблем именно благодаря существенно большей поверхности атаки ntpd и той легкости, с которой его можно сконфигурировать неправильно.

А расскажите как мне собрать udev без systemd? :) В gentoo например это делается костыльно — собирается весь systemd и из собранного дерева вычленяется udev :)
tar 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 -j4

Как мне подсказали в багтрекере systemd, можно использовать make built-sources systemd-udevd udevadm -j4. Autotools known issue.


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

systemd так-то модульный. И да, что такого плохого в ACL для логов?

То, что раньше это было сугубо опциональным, а теперь обязательно.
Во-первых, не всем это подходит: может там ФС какая-нибудь хитрая, может какие-нибудь хитрые программы с ACL плохо дружат. Это базовый компонент, он должен работать всюду и в любой возможной конфигурации ОС, а конфигурация без поддержки ACL вполне возможна, это штука не обязательная.
Во-вторых, обновляем ОС на следующий релиз и внезапно что-то ломается там, где раньше работало.

А зачем использовать кастрированные ФС? Вроде уже не каменный век, выбор есть. А программы, не дружащие с ACL, не должны использоваться в продакшне вообще. Как по мне, безопасность важнее, особенно в наши дни, когда даже деньги не так важны, как данные. Да и деньги понемногу становятся данными, если уж на то пошло.
А зачем использовать кастрированные ФС?
А программы, не дружащие с ACL, не должны использоваться в продакшне вообще.

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


POSIX ACL(кстати, в стандарт они не включены, не обманывайтесь названием) — штука опциональная. Такие низкоуровневые системные службы, как init и логгер, должны работать не зависимо от включения/выключения опциональных возможностей. Ну то есть если завтра выйдет очередной релиз ядра и Линус объявит, что начиная с этого релиза ФС без поддержки ACL перестают монтироваться — тогда можно начинать писать системный софт, который на ACL завязан.

tmpfs, куда логи пишутся по умолчанию (при форвардинге в syslog) acl поддерживает, ext2/ext3/ext4, xfs, reiserfs, jfs, btrfs, hfs+, jffs2, nfs2/nfs3/nfs4, samba, ceph, gluster — тоже поддерживают. На чём вы собираетесь держать корневую fs, если вас так беспокоит это беспокоит? Может на fat32 или ntfs? Или вы специально отключаете поддержку acl при конфигурировании ядра?

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

А тут дело в безопасносте и удобстве для админа.

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

А причём тут это? Покуда FAT32 остаётся актуальной, этого никто не сделает. Но что мешает не использовать её под системные вещи? Нужна простая ФС на раздел небольшого объёма? Есть нежурналируемая ext2. Для линуксов — нативнее некуда, её поддержка ничего не стоит, если стоит вопрос радикальной минимизации размера ядра. Её и в винде можно просматривать. Вообще, не могу представить кейс, при котором система должна быть размещена на ФС без поддержки ACL.
не могу представить кейс, при котором система должна быть размещена на ФС без поддержки ACL

NFS. ACL там есть, но это не POSIX, а свои, не совсем совместимые с POSIX ACL.


Вопрос не в том, может или нет кто-то представить такой кейс. Вопрос в том, что если стандарт допускает два варианта работы, то системный софт должен поддерживать оба варианта.

UFO just landed and posted this here

Эм… а я обязательно должен оплачивать разработку любого ПО, про которое хочу высказать своё мнение? Оплата только полностью или частичная годится?

UFO just landed and posted this here

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


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

UFO just landed and posted this here

Нет, "должен" не обязательно значит "должен мне", это так же может означать "таковы предъявляемые требования". Например: "зимнее дизтопливо должно иметь температуру застывания не более -35 C".


Такой унылый срач^W обсуждение, давайте закончим уже?

UFO just landed and posted this here
NFS. ACL там есть, но это не POSIX, а свои, не совсем совместимые с POSIX ACL.

Можно создать враппер. Это, само собой, принесёт кучу головной (и не только) боли при реализации, но с этим станет можно жить. И ещё вопрос тогда остаётся: зачем NFS для хранения системных файлов?
зачем NFS для хранения системных файлов?

Ну, допустим, загружаемый по сети тонкий клиент с маленьким объёмом памяти.


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

И зачем тонкому клиенту NFS? Логи хранить? а на кой они фиг сдались?

Нет, корень монтировать. Я видел такой вариант использования. Складывать логи на сервер тоже в принципе можно через NFS

С каких пор логи стали системными файлами?
А с каких пор логи системы таковыми не являются?

А насколько реально/правильно/эффективно использовать systemd для старта демонов? Имеется worker, который делает какую-то фоновую задачу и берет задачи из очереди (если это важно, написан на PHP). Сейчас используется supervisor. Особенно интересует вопрос запуска N копий одного и того же процесса. В supervisor решается так:


process_name = %(program_name)s-%(process_num)02d
numprocs=10

А как быть в systemd?

template unit и for ((i=0; i<10; i=i+1)); do systemctl enable --now worker@$i ; done

Ну вполне реально использовать шаблоны — как пример /lib/systemd/system/getty@.service и соответственно getty@tty1.service
Вполне себе используется во fleet на coreos.

update: Я буду обновлять страницу перед написанием комментария :)
Вы не написали основную проблему systemd — нестабильность.
Если по какой-то причине любая часть systemd заглючит, с большой вероятностью init процесс будет работать некорректно или упадет. если упадет init, то упадут все процессы.
Т.к. systemd лепит почти все функции в init процесс. Тоже самое с безопасностью, т.к. все части обращаются к init процессу, его могут поломать.

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

Или еще одна проблема из-за systemd, теперь много софта собирается с поддержкой systemd, и не может без него работать.
На пример если взять debian, чтобы записать cd через графическое приложение, systemd обязателен. Но какое отношение systemd имеет к записи cd? Права? так можно было сослаться что нет прав на устройство.

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

Другая проблема, не знаю может её уже исправили. Если при загрузке включить лог ядра, то systemd зависает или падает.

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


Вы не написали основную проблему 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-серверами. И который, естественно для всех кроме хейтеров, можно не собирать и/или не паковать, если не надо.

Вот такие вот «изолированные» сервисы www.opennet.ru/opennews/art.shtml?num=50168

dbus в pid1, вот об этом я писал. не думаю что хоть один другой инит может уронить pid1 от dbus сообщения или еще какого либо действия, которое не должно обрабатываться в pid1. И это не случайная ошибка. Это системная ошибка, там все сделано не совсем корректно.
UFO just landed and posted this here
Криво можно сделать и сейчас и в 1994.
Я не говорю что systemd это совсем уж плохой продукт, в нем есть много чего хорошего. Но безопасность там на «отцепись». Также разработчики очень плохо реагируют на баги и уязвимости. Основная проблема что вот это вот все, что вроде как новое, но с никакой безопасностью и надежностью, запихали почти во все дистрибутивы. И этот треш больше нельзя не использовать. Не важно есть ли более безопасные реализации или нету, и systemd использовать приходится…

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

Добавление заведомо уязвимой функции в pid1 это ни как не добавляет безопасности и надежности.
UFO just landed and posted this here
На счет пруфов смотрите багтрекеры systemd и debian'а. Плохо реагируют не значит что совсем ничего не исправляют, но могут исправить так, что лучше бы и не исправляли вовсе. Скажем вместо простого багфикс релиза, заставлять использовать очередной релиз, в котором куча всего добавлено/изменено включая нужный баг.

общение любого процесса с init это увеличение поверхности атаки, без какого либо практического смысла. Это тоже самое что, на пример повесить локальный mysql на публичный ip без фаервола, и сказать: ну и что, там все равно пароль требуется, и ничего что работа с mysql идет только локально.

На счет пруфов не копался в исходниках systemd, мне это совсем не интересно. Мне надо чтобы init просто работал, но systemd постоянно что-то ломает или сам не работает. Но если разработчики считают что в pid1 можно добавит dbus, то что им мешает добавить туда на пример dns клинт? А чего это тоже важная функция, и ничего что в pid1 она не нужна, зато «так надежнее».
Скажем вместо простого багфикс релиза, заставлять использовать очередной релиз, в котором куча всего добавлено/изменено включая нужный баг.

Мягко говоря, это не правда. Потому, что все багфиксы бэкпортируются на более чем 20 версий назад в специальном репозитории https://github.com/systemd/systemd-stable


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

UFO just landed and posted this here
UFO just landed and posted this here
В комментарии, на который вы ответили, никто не утверждал, что все надо делать как в 1994-м. Что вы имели в виду под «натягиванием совы на глобус» тоже не понятно.
У systemd помимо бинарных логов, которые сложно разбирать вручную, есть интересный недостаток по сравнению с SysVinit. В /etc/init.d/foobar я могу использовать свою команду, например, info, чтобы быстро получить существенную информацию от демона о его состоянии. В скрипте в case-ветке «info)» тривиально отфильтровать нужное из результата запроса к демону. В случае systemd свои команды непонятно как делать, приходится писать дополнительные скрипты сложности прежнего инит-скрипта. То есть делаем ту же работу, что и для SysVinit плюс работу для systemd.

Развейте мой заблуждение.

systemd не запрещает делать свои команды, если нужна нестандартная/расширенная информация от конкретного сервиса: можно положить скрипт, дающий нужное представление. Но systemctl status для этого не предназначен. Так в большинстве случаев было и при sysv, и при upstart'е.


См. также http://stackoverflow.com/a/39109294.

Sign up to leave a comment.

Articles