Опубликован видеоурок "Systemd In Action", первый из серии, рассказывающей об устройстве systemd на реальных примерах. Systemd - это не система инициализации и даже не "системный менеджер" (как можно прочитать на freedesktop.org в описании компонента). Systemd как проект - это универсальный plumbing layer, набор служебных программ для совершенно разных задач. Основная идея этого проекта состоит в централизации управления ключевыми системными компонентами "всё в одном". Это сделано, в основном, чтобы упростить администрирование и повысить надёжность за счёт интеграции и более тесного взаимодействия.
В данном эпизоде рассмотрена непосредственно система инициализации (также называемая systemd), её основные концепции и принципы работы.<center><iframe width="640" height="480" src="//www.youtube.com/embed/pSTo-VY6kno?rel=0" frameborder="0" allowfullscreen></iframe></center>
URL: http://tlhp.cf/sia1
Новость: http://www.opennet.me/opennews/art.shtml?num=41074
Отлично, то что нужно.
> Отлично, то что нужно.по "ненужно" :)
это, как я понимаю, только первая серия на 1.5 часа? :)
Отлично, актуально нынче для дебиановодов.
Дебиановоды и так проходят этот цирк живьём, пока на примере центра проекта.
Мишаня сегодня в неадеквате ?
> Мишаня сегодня в неадеквате ?Да у него это в последнее время на волне политических обострений почти постоянно - везде видит нечто типа заговора и норовит воевать с ветряными мельницами, чуть кто минимально не согласен с его Единственно Правильным Мнением (хотя МСовские боты наверное развитию такого поведения немало способствовали). Но немного его разочарую: с дебианщиков все-равно альту ничего не обломится. А таких закидонов какие демонстрируют он и Led - достаточно для того чтобы отпугнуть на пушечный выстрел любого пользователя с минимальными остатками адеквата. Даже с Торвальдсом можно поспорить, если аргументы есть. Но Шигорин видимо считает себя сильно круче и не допускает даже мысли что его видение ситуации - отнюдь не абсолютная истина в последней инстанции. А Led так и вовсе скатился в голословные необоснованные нападки на уровне условных рефлексов.
Граждане, так себя вести - это просто позорище! И это проекты к которым вы причастны это все совсем не украшает.
>[оверквотинг удален]
> Но немного его разочарую: с дебианщиков все-равно альту ничего не обломится.
> А таких закидонов какие демонстрируют он и Led - достаточно для
> того чтобы отпугнуть на пушечный выстрел любого пользователя с минимальными остатками
> адеквата. Даже с Торвальдсом можно поспорить, если аргументы есть. Но Шигорин
> видимо считает себя сильно круче и не допускает даже мысли что
> его видение ситуации - отнюдь не абсолютная истина в последней инстанции.
> А Led так и вовсе скатился в голословные необоснованные нападки на
> уровне условных рефлексов.
> Граждане, так себя вести - это просто позорище! И это проекты к
> которым вы причастны это все совсем не украшает.Дорогой анонимный Брат, ты напрасно упомянул имя Светодиода всуе, ща набежит сделает скандал, "навалит" кирпичей, а виноватым останешься ты. Ну а Светодиод как всегда на белом единороге ускачет в светлую даль, дожидаться следующего "прихода"...
А Мишаня... его действительно можно много где в интернетах встретить, но надо отдать ему должное - в большинстве случаев строг, но справедлив.
> везде видит нечто типа заговора и норовит воевать с ветряными мельницамиСкорее "обжёгшись на молоке, дует и на воду". Довольно неприятно пытаться что-либо объяснять боевикам в своём городе, до того легкомысленно отнесясь к бандеровским анекдотам. Надеюсь, Вам такого не выпадет.
> чуть кто минимально не согласен с его Единственно Правильным Мнением
Ещё чего не хватало. Моё мнение всего лишь основано на моих наблюдениях, это не значит, что у других могут быть другие наблюдения (даже тех же событий), другое осмысление, соответственно и опыт, и мнение. Бывает и разное понимание тех же слов.
> Но немного его разочарую: с дебианщиков все-равно альту ничего не обломится.
"С дебианщиков" альту регулярно "обламывается" что пользователей, что разработчиков (и порой сотрудников); так же и дебиану с альта бывали пользователи, разработчики, издания на DVD в ту пору, когда мало кто мог позволить себе вытащить эти гигазы. Тут как раз всё в порядке :)
> А таких закидонов какие демонстрируют он и Led
К Саше вообще полезен переводчик, не стоит судить его по словам -- если хочется понять, лучше смотрите коммиты.
> Даже с Торвальдсом можно поспорить, если аргументы есть.
Факт, за то и любим.
> Но Шигорин видимо считает себя сильно круче и не допускает даже мысли что
> его видение ситуации - отнюдь не абсолютная истина в последней инстанции.Это не так, изредка меня переубеждали и в важных вещах, предъявив вещдоки и аргументы.
А по второ- и тем более третьестепенным нередко может показаться, что иду напролом там, где всего лишь стараюсь положить и на вторую чашу весов то, что знаю, ради более полного рассмотрения. Проблема известна, решение в общем случае пока не найдено.
Когда оппоненты не склонны ввязываться в спор ради спора, а стремятся что-либо для себя из обсуждения вынести -- оно обычно быстро сходится и бывает полезным.
> Граждане, так себя вести - это просто позорище! И это проекты к
> которым вы причастны это все совсем не украшает.Это понятно, но истина -- уж какой вижу -- дороже "имиджа". Но всяко спасибо, дружище.
> Довольно неприятно пытаться что-либо объяснять боевикам в своём городе, до того легкомысленно отнесясь к бандеровским анекдотам. Надеюсь, Вам такого не выпадет.Мишаня, мы тебе сочувствуем и относимся со всем возможным пониманием, уж поверь.
> К Саше вообще полезен переводчик, не стоит судить его по словам --
> если хочется понять, лучше смотрите коммиты.Ты верно шутишь ?
Как это не судить по словам, а по коммитам ? Ты это ещё судье напиши, который Ганса на долгие годы на тюрма поставил - какой же он преступник, у него коммитов на пятерых хватит.
Светодиоду надо над собой поработать, иначе и он может плохо кончить. Коммиты коммитами, но чувак выдаёт на форуме явно неадекватные, как бы это помягче сформулировать... каловые массы. И это бросает тень, не только на него самого. Можешь ему сообщить, что дистр сотрудничающий с буйнопомешанными получает от этого дурную ауру в глазах пользователей и они на такой дист забивают.
>> К Саше вообще полезен переводчик, не стоит судить его по словам --
>> если хочется понять, лучше смотрите коммиты.
> Ты верно шутишь ?Нет.
> Как это не судить по словам, а по коммитам ?
Читая.
Лолчто? Только OpenRC, только хардкор!
> Лолчто? Только OpenRC, только хардкор!А мне не надо хардкор. Мне надо простое и удобное выполнение типовых операций. А кому хардкор - пусть идет hurd кодить.
хотелось бы возможность заливки и просмотра офлайн, есть ? посмотреть\послушать в метров\автобусе
youtube-dl. да и вебсервисов тьма, стыдно линуксоиду спрашивать такое.
Вы всё ещё кипятите? Тогда мы идём к вам.
YouTube Center, хотя для целей добавления кнопки для скачивания, сущесвтует тысяча и один скрипт
> YouTube Center, хотя для целей добавления кнопки для скачивания, сущесвтует тысяча и
> один скриптЧувак, ютуб в HTML5 - обычный веб. И мувик может скачать любая качалка. Ну там wget, DownThemAll из лисы, да даже простой save as из сведений о странице. Какие нафиг скрипты, вы о чем?
мне не стыдно ибо знаю
сырец мне дай (про это спрашивал), а там уж разберусь в каком формате и качестве мне это все нужно
360:https://r5---sn-4g57knek.googlevideo.com/videoplayback?nh=Ig...
720:
https://r5---sn-4g57knek.googlevideo.com/videoplayback?nh=Ig...
в url перед youtube добавь ss (ssyoutube) нажми enter и скачивай в каком хочешь качестве. Сам уже качаю.
А могу я как-то просмотреть это видео посредством самого systemd? Обычно там есть вещи на все случаи жизни, эталонные и прозрачные(с).
Конечно, вот тебе экземпляр модуля =)
===============================
[Unit]
Description=Show video[Service]
ExecStart=/usr/bin/mplayer -vo=fbdev https://r5---sn-4g57knek.googlevideo.com/videoplayback?nh=Ig...[Install]
WantedBy=multi-user.target
===============================[сообщение отредактировано модератором]
Блин, как же оперы не хватает.
> Блин, как же оперы не хватает.Не, знаешь, интегрировать в системдэ оперу - это как-то слишком круто.
>Не, знаешь, интегрировать в системдэ оперу - это как-то слишком круто.Оперу - не, надо какой-нибудь iceweasel или icecat.
>>Не, знаешь, интегрировать в системдэ оперу - это как-то слишком круто.
> Оперу - не, надо какой-нибудь iceweasel или icecat.А то получится системдэ-опердэ и в банках будет паника? :)
systemd это уже религия, абсолютно бесполезная система. Запихать все в одну кучу чтобы было легче администрировать, вот это "аргумент".
> systemd это уже религия, абсолютно бесполезная система. Запихать все в одну кучу чтобы было легче администрировать, вот это "аргумент".Нормальный народ изучает perl чтобы было легче администрировать.
> Нормальный народ изучает perl чтобы было легче администрировать.Изучить можно что угодно, и perl тоже. Дело просто в том что systemd создают как бы для решения многолетних недостатков. Например init файлы на bash, которые якобы сложные, для понимания пользователя. Так вот пользователь если туда полез значит должен знать зачем он там, а если не знает то и лезть не стоит.
Мне не нравится systemd, потому что он хочет делать все, даже то что делать не должен. не говорю что все идеи systemd плохие, просто некоторые идеи должны быть частью отдельных проектов а не все в одном. А скорость загрузки на 1 секунду быстрее чем у других систем инициализации это вообще не аргумент даже на серверах.
> А скорость загрузки на 1 секунду быстрее чем у других систем инициализации это вообще не аргумент даже на серверах.Даже? На серверах это вообще не актуально.
Зато на серверах актуальна масса других преимуществ systemd.Собственно, неудивительно, что Red Hat, зарабатывающая именно на серверных платформы так много делает для развития systemd и интеграции с ним. В конце концов, какая там система инициализации на десктопе, обычно волнует только мейнтейнеров. У пользователя работает - и ладно. А вот на сервере от нее требуется намного больше, и там многие фичи systemd оправданы в первую очередь. Но не быстрая загрузка, пожалуй. Хотя она тоже неплоха.
$ systemd-analyze
Startup finished in 22.851s (firmware) + 10.508s (loader) + 2.187s (kernel) + 4.872s (initrd) + 30.460s (userspace) = 1min 10.880sС upstart в EL6 тут было минуты три примерно, когда сервисы потихонечку запускались один за другим, после полной инициализации каждого.
(кстати, любопытно время загрузки firmware. Ни на одной другой машине это не указывается. Наверняка тут необходим UEFI, но это не единственная машина с UEFI, на которой я запускал systemd-analyze - но это время указывается только тут)..
> Зато на серверах актуальна масса других преимуществ systemd.Каких именно - изменения конфиг файлов на лету или бинарные логи?
> Зато на серверах актуальна масса других преимуществ systemd.Не надо лукавить, ведь быстрая загрузка systemd, основана на параллельном запуске сервисов. Это значит на момент когда пользователь получает приглашение системы на вход, визуально systemd прекратил загрузку но по факту некоторые сервисы еще загружаются
>> Зато на серверах актуальна масса других преимуществ systemd.
> Не надо лукавить, ведь быстрая загрузка systemd, основана на параллельном запуске сервисов.
> Это значит на момент когда пользователь получает приглашение системы на вход,
> визуально systemd прекратил загрузку но по факту некоторые сервисы еще загружаютсяТ.е. сервер уже какбы и загрузился, но на запросы еще не отвечает, ибо "некоторые сервисы еще загружаются", а если их загрузить не удастся, то и отвечать не будет, зато "визуально systemd прекратил загрузку". Да, очень востребованное "преимущество", особенно на серверах.
>Каких именно - изменения конфиг файлов на лету или бинарные логи?Вот мне тоже очень интересно. Апеллировать к быстрой загрузке - это вообще не агрумент, т.к. у меня, к примеру, на ноуте прямо сейчас аптайм в 120 дней.
>> Зато на серверах актуальна масса других преимуществ systemd.
> Каких именно - изменения конфиг файлов на лету или бинарные логи?systemd четко отслеживает, какие сервисы и как работают, с помощью cgroups отслеживая pid'ы.
Это дает массу возможностей, как то:
1) Можно посмотреть, какие сервисы отказали и не работают прямо сейчас
2) Можно гарантировано убить сервис, не оставив "хвостов" (в sysvinit в случае fork'анья демона приходится надеяться, что дети действительно умрут при умирании родителя - что, в общем, не гарантировано)
3) Делает ненужным инструменты типа supervisord, daemontools, runit, позволяя решить аналогичную задачу "вот эту простую софтину перезапускать при падении и перехватывать вывод в лог-файл" штатными средствами, что намного проще и удобнее, чем "двухуровневый" init, который приходилось использовать в реальности до прихода systemd (тот же runit теоретически может быть основным init'ом, но кто-нибудь такое в жизни в продакшене видел??)
4) Дает возможность просто обертывать в сервисы "непослушные" сервисы, особенно на python/java, не ведущие pid'ов. Если вы когда-нибудь видели порятнки башевского кода, необходимые для корректного останова/перезапуска java-софтины или получения информации о том, работает ли она еще, вы поймете. Автоматическое отслеживание pid'ов через cgroup решает эти проблемы
Во первых не отслеживает какие сервисы работают, а отслеживает какие сервисы упали. То что сервис не упал еще не значит что он работает.Во вторых работа с cgroups реализована и отдельными приложениями вне systemd. Так что systemd делает здесь то-же что уже сделано, только на свой манер - прибивая гвоздями.
В третьих исключает дополнительные кастумные инструменты, признавая верной только генеральную линию партии - а это правильно? Если в supervisord я могу легко допитонячить свой watchdog с логикой то тут два пути - либо писать его на C и потом поддерживать свой форк, либо иcпользовать supervisord...
То есть по сути все эти фитчи уже есть в продакшене, но их реализует не init, а сторонние тулзы.
Теперь повторю вопрос - в чем преимущества systemd которые актуальны на серверах? То что наличие выбора сведено к единственно "верному" решению от Поттеринга?
> Во первых не отслеживает какие сервисы работают, а отслеживает какие сервисы упали. То что сервис не упал еще не значит что он работает.А вы туда искусственный интеллект предлагаете воткнуть? Первые же будете кричать, что мол слишком много он на себя тянет. Может он должен уметь определять, что сервис работает не совсем так, как хотели пользователи, например, и писать админу письмо с рекомендацией, как правильно перенастроить сервис?
Конечно, которые упали. Это часто уже большая помощь.
> Во вторых работа с cgroups реализована и отдельными приложениями вне systemd. Так что systemd делает здесь то-же что уже сделано, только на свой манер - прибивая гвоздями.
В смысле?
Systemd - единственный известный мне сервисный менеджер, который честно отслеживает pid'ы и потомки по cgroups. И делает это абсолютно корректно и эффективно. Ни в одном другом init'е эта фича на таком уровне реализована, они все либо отслеживают только непосредственно один процесс, не отключащийся от терминала и ни в коем случае не форкающийся, либо начинаются хитрости с записью и чтением pid-файлов, сравнением их актуальности с выводом pgrep и прочая муть. Иногда неплохо работает для наколенного скрипта, но от системного менеджера сервисов хотелось бы понадежнее.> В третьих исключает дополнительные кастумные инструменты, признавая верной только генеральную линию партии - а это правильно? Если в supervisord я могу легко допитонячить свой watchdog с логикой то тут два пути - либо писать его на C и потом поддерживать свой форк, либо иcпользовать supervisord...
И откуда вы такие беретесь?
systemd это *полностью* SysV-init совместимый менеджер. Поставьте в сервис-файле опцию, чтобы не отслеживал и запускал только ваш мастер-процесс и дальше городите свою иерархию, как вам там отслеживать, убивать и перезапускать детей ручками. Кто мешает-то? Причем тут C вообще??> То есть по сути все эти фитчи уже есть в продакшене, но их реализует не init, а сторонние тулзы.
Этих фич вне systemd НЕТ в продакшене. Ни в каком supervisord или runit вы не найдете настоящего отслеживания процессов.
Зачем искусственный интеллект?! Просто у каждого сервиса обычно есть свой механизм мониторинга. Настроить и запрограммировать его не проблема всякому кто немного знаком с программированием. Только я говорил о другом что предложенный в systemd метод хоть и подспорье, но не серебренная пуля, и проблему отказа сервера придется решать альтернативным watchdog-ом, а уже его уговорить за компанию pid мониторить дело техники.Почему именно в init-е вы хотите отслеживать pid? Утилиты для взаимодействия с cgroups есть в командной строке, а SysVinit сценарии пишутся на шелле. Ну - это как бы намек. Если вам нужен такой строгий мониторинг беглецов вы и занимайтесь, не перекладывайте это на здоровую голову... Процент тех у кого много побегов очень мал... И еще - если сервис бегает может это в нем проблема а не в системе иницализации?
> systemd это *полностью* SysV-init совместимый менеджер.
Конечно полностью совместимый, но если его так использовать получается тот самый двух - трех уровневый инит от которого Вы так плевались.
> Этих фич вне systemd НЕТ в продакшене. Ни в каком supervisord или runit вы не найдете настоящего отслеживания процессов.
Все это реализуется несколькими сценариями на shell. Как вы сами признаете, если вам интересно что-то больше чем упало - подними, от двууровневой инициализации не уйти.
То есть фитча в тупом админе, который не может прочитать как пользоваться cgroups, но может "админить"?
> сервера придется решать альтернативным watchdog-ом, а уже его уговорить за компаниюЯ просто оставлю это здесь
http://0pointer.de/blog/projects/watchdog.htmlпо остальному комментировать даже не хочется. Если вы никогда не правили sysvinit-скрипт со всей функциональностью (restart, condrestart, мягкий шатдаун + форсированный после таймаута) для java-программы, я не смогу объяснить, что такого замечательно в отслеживании сервисов методами systemd.
> по остальному комментировать даже не хочется. Если вы никогда не правили sysvinit-скрипт
> со всей функциональностью (restart, condrestart, мягкий шатдаун + форсированный после
> таймаута) для java-программы, я не смогу объяснить, что такого замечательно в
> отслеживании сервисов методами systemd.А покажите, кстати, пример с мягким. Инитскрипты такие видел и не только для java.
> А покажите, кстати, пример с мягким. Инитскрипты такие видел и не только для java.Эээ а что там собственно показывать? Он по дефолту уже так работает - убивает обычным сигналом все процессы в контрольной группе, ждет таймаута, потом убивает KILL'ом. Но можно настраивать кого убивать, как убивать в первый раз, сколько ждать и что делать вместо KILL'а (все опции описаны в http://www.freedesktop.org/software/systemd/man/systemd.kill... + опция ExecStop в основном мане)
> Я просто оставлю это здесь
> http://0pointer.de/blog/projects/watchdog.htmlПо моему loopbase watchdog это немного не то, о чем я говорил. Как то любой event-based сервис, временами, очень по долгу висит в состоянии одного лупа. Да и идея модифицировать код сервиса чтобы можно было его мониторить watchdog-ом systemd это ни разу не ынтерпрайз идея...
> по остальному комментировать даже не хочется. Если вы никогда не правили sysvinit-скрипт
> со всей функциональностью (restart, condrestart, мягкий шатдаун + форсированный после
> таймаута) для java-программы, я не смогу объяснить, что такого замечательно в
> отслеживании сервисов методами systemd.Сказанное никак не опровергает то факт что реализовать этот функционал можно без systemd, но с теми же cgroups. Ну к примеру так http://hydra.geht.net/tino/english/faq/debian/squeeze/cgroups/.
То что вы утверждаете о своем опыте написания сценариев инициализации, и о неоптимальности найденого решения, не доказывает, что не существует более оптимального решения. Как и не доказывает ваш изначальные тезис, что данные приемы можно осуществить только в systemd.
А апелляция к отсутствию опыта <..нужное подставить..>, и утверждение о том что, без такого опыта нельзя рассказать есть разновидность аргумента Ad-homine. Если все так страшно - есть pastebin - покажите нам страх и ужас. Здесь все свои - мы поймем...
>> Во первых не отслеживает какие сервисы работают, а отслеживает какие сервисы упали.Кстати, исключительно верное замечание.
> А вы туда искусственный интеллект предлагаете воткнуть?
http://mmonit.com/monit/documentation/monit.html#SERVICE-TESTS
http://mmonit.com/monit/documentation/monit.html#CONNECTION-...> Первые же будете кричать, что мол слишком много он на себя тянет.
Да нет, кое-что из такого вполне сочетаемо с дистрибутивной конфигурацией сервисов даже.
> Конечно, которые упали. Это часто уже большая помощь.
Да, но и самоуспокоение в случае залипания. Ведь тема мониторинга уже вроде бы как закрыта, ничего делать не надо, верно?
> Этих фич вне systemd НЕТ в продакшене. Ни в каком supervisord или
> runit вы не найдете настоящего отслеживания процессов.Остерегайтесь подделок! Выбирайте только Genuine Process Tracking(tm).
И пофиг, что контейнеры -- которые предоставляют более сильную изоляцию, чем просто cgroups -- давным-давно используются в этом самом production.
> http://mmonit.com/monit/documentation/monit.html#SERVICE-TESTSВот кстати ссылка выше (про watchdog) покрывает часть кейзов. Я имею ввиду вторую часть статьи про watchdog приложений, разумеется.
Что касается monit, то разумеется systemd не заменит хорошо настроеный monit, но.. если очень хочется :)
https://ask.fedoraproject.org/en/question/44938/can-systemd-.../В любом случае, мы живем в реальном мире. Где-то существуют системы, в которых все сервисы, влияющие на работоспособность обернуты monit, но в мире, где я живу, такой роскоши нет и не предвидится, т.к. ни у кого нет на это сил/времени. В этом мире сервисы бывают, грубо говоря, двух типов: системно-дистрибутивные - со встроенной мониторилкой/перезапускалкой а-ля httpd, не всегда покрывающей 100% кейзов, либо просто падающие при отказе. Для таких мониторинг писать лень, т.к. их масса на куче серверов. И возможность с приходом systemd увидеть, что именно не работает - причины-то банальные обычно, а отказ многих некритичных сервисов не заметен сам по себе - это благо. monit тут не спасает, вернее спасает только теоретически.
Второй тип - свои (разрабатываемые) или купленные или другие подобные "левые" сервисы. Обычно вешаются под перезапускалку типа supervisord (а теперь можно прямо под systemd), подключатся к анализатору логов и снимаются показатели в zabbix или nagios. При таком типе мониторинга monit тоже вроде как ни при делах. А от systemd польза оказалась. (ок, раз мы заговорили о жизни - в жизни, скорее всего, в ближайшие годы от второго уровня init'а и левых перезапускалок никуда не деться, т.к. systemd внедрен в продакшене недостаточно, а стратегия "запускать всегда под supervisord, а под чем запускается он сам - upstart или systemd, без разницы" дает универсальность. Но это вопрос времени)Я понимаю, что и от monit есть прок, но по факту вижу кучу примеров, когда systemd полезен, а с monit никто и заморачиваться не будет. Если сервис критичен, нужно постараться воткнуть несколько копий с каким-либо load balancing'ом и подключить мониторинг общих очередей в zabbix, и падения отдельных инстансов перестают быть критической ситуацией.
> Да, но и самоуспокоение в случае залипания. Ведь тема мониторинга уже вроде бы как закрыта, ничего делать не надо, верно?
По моему опыту, большая часть системных сервисов отваливается, а не залипает.
В любом случае, покрыть часть кейзов это лучше, чем ничего. Запустить systemctl и посмотреть, что точно упало - это не проверка работоспособности сервера, а один из многих шагов поиска проблем. И хорошо, что есть такая возможность.> И пофиг, что контейнеры -- которые предоставляют более сильную изоляцию, чем просто cgroups -- давным-давно используются в этом самом production.
Я не про изоляцию. Я знаю, что cgroups много для чего используются. Те же ограничения потребления ресурсов виртуалок через них сделаны. Я про то, что systemd - первое решение, предлагающее надежное отслеживание всех сервисов их потомков в противовес созданию pid-файла, поиска процесса в списке, сравнения актуальности с pid-файлом, проблем с отпочковавшимися детьми и прочим.
> https://ask.fedoraproject.org/en/question/44938/can-systemd-...Спасибо, узнал про systemd mailer. Но какие же там предлагаются портянки вместо простого и понятного (в т.ч. документированного) языка monitrc...
> В любом случае, мы живем в реальном мире. Где-то существуют системы, в
> которых все сервисы, влияющие на работоспособность обернуты monit, но в мире,
> где я живу, такой роскоши нет и не предвидится, т.к. ни
> у кого нет на это сил/времени.Просто к сведению -- кусочки конфигурации можно дёргать из альта, там хороший набор дополнений: http://packages.altlinux.org/ru/Sisyphus/srpms/monit/sources...
> Для таких мониторинг писать лень, т.к. их масса на куче серверов.
> [...] monit тут не спасает, вернее спасает только теоретически.Кого как -- если дистрибутив и пакетная база являются данностью, то скорее да. А если можно сделать хорошо не только на локалхостах, то нет. Проверено.
> Второй тип - свои (разрабатываемые) или купленные или другие подобные "левые" сервисы.
> Обычно вешаются под перезапускалку типа supervisord (а теперь можно прямо под
> systemd), подключатся к анализатору логов и снимаются показатели в zabbix или
> nagios. При таком типе мониторинга monit тоже вроде как ни при делах.Потому что вместо него взят supervisord, который был бы не при делах, если бы взят был тот же monit? :)
> от [...] левых перезапускалок никуда не деться, т.к. systemd внедрен
> в продакшене недостаточно, а стратегия "запускать всегда под supervisord,
> а под чем запускается он сам - upstart или systemd, без разницы" дает
> универсальность. Но это вопрос времени)Думаю, нет -- это типовое generalist vs specialist, комбайн vs инструмент. Т.е. баланс ещё сползёт, но и только.
> Я понимаю, что и от monit есть прок, но по факту вижу кучу примеров, когда systemd
> полезен, а с monit никто и заморачиваться не будет.Это понятно, но с моей колоколенки кажется проблемой образования и подхода -- когда этот "никто" не склонен "заморачиваться", косяки у него вылезут не здесь, так там.
> Если сервис критичен, нужно постараться воткнуть несколько копий с
> каким-либо load balancing'ом и подключить мониторинг общих очередей в zabbix,
> и падения отдельных инстансов перестают быть критической ситуацией.Кстати, у меня сложился рабочий вывод, что мониторинг хорош активный локальный с пассивным распределённым.
> По моему опыту, большая часть системных сервисов отваливается, а не залипает.
Да, залипания реже. Но у них и воспроизводимость с предсказуемостью сильно ниже.
> В любом случае, покрыть часть кейзов это лучше, чем ничего.
Зависит от того, считается ли полученный полстакан "наполовину полным" (закрытым вопросом) или "наполовину пустым" (открытым и требующим доработки).
> Запустить systemctl и посмотреть, что точно упало - это не проверка работоспособности
> сервера, а один из многих шагов поиска проблем. И хорошо, что есть такая возможность.Эт понятно.
> Я не про изоляцию.
А я вполне сознательно про неё. Потому что отслеживание одичавших процессов -- очередная полумера, в то время как рассаживание не нуждающихся в общих пространствах имён процессов именно по контейнерам позволяет обеспечивать заметно большую эксплуатационную надёжность по сумме факторов, включая и обновления, и заменяемость/масштабируемость.
> Я про то, что systemd - первое решение, предлагающее надежное отслеживание всех
> сервисов их потомков в противовес созданию pid-файла, поиска процесса в списке,
> сравнения актуальности с pid-файлом, проблем с отпочковавшимися детьми и прочим.А знаете, чего от этого подхода ждать? Дальнейшего понижения планки -- "да чего я буду следить за детишками, пусть полицай следит".
> А я вполне сознательно про неё. Потому что отслеживание одичавших процессов
> -- очередная полумера, в то время как рассаживание не нуждающихся в
> общих пространствах имён процессов именно по контейнерам позволяет обеспечивать заметно
> большую эксплуатационную надёжность по сумме факторов, включая и обновления, и заменяемость/масштабируемость.Изоляция это хорошо, но слишком сложно. Нет, я понимаю что конкретный сервис отправить в изоляцию так не сложно, особенно на современной системе. Но, к примеру, половину системных сервисов?? Слишком много возни. Делать контейнеры с кучей системных файлов и т.д. С Docker уже получше, конечно (недавно смотрел презентацию http://redhat.slides.com/jduncan/wrinkle-free-docker-20141107#/ - просто конфетка. Но, имхо, еще в продакшен рано..). А в systemd это "бесплатно" для всех сервисов уже есть.
С обновлениями не все так просто. Если у меня будет 30 контейнеров, как обновлять во всех библиотеки и сколько это времени/ресурсов займет? У нас все-таки не солярисовские зоны, где эти проблемы с помощью zfs эффективно решаются.. Ну и так далее.
> А в systemd это "бесплатно" для всех сервисов уже есть.А я о чём толкую? Получается некоторое улучшение ситуации по умолчанию (что важно) и типичная ориентация на эникейщика. К чему индус-триализация приводит штатовские софтовые лавки, легенды уж давно складывают.
Те олухи, что тут бегают порой и орут про дворников, не понимают, что они даже при своей нулевой в основном квалификации окажутся не дешевле таких же нулевых индусов или бразильцев (или хорошо замаскировавшихся бывших протоукров, "встречайте на экранах"). Для работодателя же подобные процессы чреваты ...вендорлоком и отсутствием компетенции на борту -- где бы я такое уже видел...
> С обновлениями не все так просто. Если у меня будет 30 контейнеров,
> как обновлять во всех библиотеки и сколько это времени/ресурсов займет?Для компактных (типично для того же альта) -- сравнительно немного, хоть и больше, чем для одного. Обратная сторона изоляции.
Если на каждый чих по полгига-гигу рожать, то грустно становится быстрей, понятно...
> В любом случае, мы живем в реальном мире. Где-то существуют системы, в
> которых все сервисы, влияющие на работоспособность обернуты monit, но в мире,
> где я живу, такой роскоши нет и не предвидитсяЗабавно, но вчера в monit-dev@ отписался страждущий, который пытается собрать его под cygwin -- говорит, configure: error: Architecture not supported: CYGWIN_NT-5.2
скорость загрузки у системдэ ниже, гораздо ниже.
> скорость загрузки у системдэ ниже, гораздо ниже.Сейчас на наблюдаемом (мои регулярки) образы с systemd грузятся чуть быстрее, чем с sysvinit, выключаются практически моментально. Но шаг в сторону -- и таймауты, особенно неприятные тем, что никаким ^C их не прервать.
Получается, что хорошо настроенная система от системд выигрывает, плохо настроенная/поврежденная - проигывает?
>> systemd это уже религия, абсолютно бесполезная система. Запихать все в одну кучу чтобы было легче администрировать, вот это "аргумент".
> Нормальный народ изучает perl чтобы было легче администрировать.пегл мертв. и уже даже не воняет.
Честно говоря звучит смешновато. Т.к. если он и "мёртв", то _возможно_ для "стильно-модно-молодёжных" свистопердельных проектов. Что впрочем не отменяет наличие ряда более чем работоспособных проектов на нём же в крупных компаниях.Но вообще-то речь шла не об этом, а о Perl как о инструменте *администрирования*. И для этого он более чем жив т.к. для этого особых стильно-модных наворотов в ЯП не требуется.
> Честно говоря звучит смешновато.Да ладно, это ж тигар. От заядлого фрюшника такое услышать необычно даже.
И что обычно пишут админы на перле для "администрирования"? Скрипты для пупета? Почему не на баше?
Если бы ты год хотя бы писал на баше и на перле -- таких бы глупых вопросов не задавал.
Предназначение "баш-скриптов" - связка из вызовов других скриптов/программ + несложная логика. Писать на нём что-либо сложное - умучаешься. Ктому же за башизмы в шелл скриптах полагается бить по рукам.
>И что обычно пишут админы на перле для "администрирования"? Скрипты для пупета? Почему не на баше?Test::More помогает легко протестировать работу систем/подсистем сервера, а Net::Jabber позволяет увидеть предупреждения, ошибки, статистику и пропарсенные логи у вас на Anrdoid-смартфоне. Можете сделать поддержку некоторых команд через jabber чтобы, например, получить grep-нутый остаток syslog'а. Ах да, у вас же логи бинарные...
> получить grep-нутый остаток syslog'а. Ах да, у вас же логи бинарные...Но даже это можно решить на Perl! :-)
>Но даже это можно решить на Perl! :-)Ну я и раньше знал что Perl можно решить ПОЧТИ все. Но после того как увидел это http://www.perlmonks.org/?node_id=738658 я понял что НА Perl МОЖНО РЕШИТЬ ВСЕ.
>> systemd это уже религия, абсолютно бесполезная система. Запихать все в одну кучу чтобы было легче администрировать, вот это "аргумент".
> Нормальный народ изучает perl чтобы было легче администрировать.При чём здесь perl? perl вместо systemd что ли предлагаете внедрить? :-)
>При чём здесь perl? perl вместо systemd что ли предлагаете внедрить? :-)Нет. Если читать внимательно, то можно понять что речь шла о "чтобы было легче администрировать".
> Нормальный народ изучает perl чтобы было легче администрировать.Нормальный народ не заказывает такси. Вместо этого они изучают металлообработку и делают себе автомобили сами.
>Нормальный народ не заказывает такси. Вместо этого они изучают металлообработку и делают себе автомобили сами.Не-не, не так все было. Вот как надо: нормальный народ не кушает, не спит, да и вообще не живет свои жизни, а ищет исполнителя.
PS: Я бы с великим удовольствием сделал бы автомобиль себе сам и поддерживал бы его жизнеспособность, модернизировал бы его по надобности, но пока ресурсы не позволяют.
немножко не для этого, не для "лёгкости администрирования" это делается, а чтобы потом заявить права на полсистемы !!!!! и прибрать к рукам ! останется только свободное ядро :(
т.е. потом возьмутся за него.ваш КЭП
> немножко не для этого, не для "лёгкости администрирования" это делается, а чтобы
> потом заявить права на полсистемы !!!!! и прибрать к рукам !
> останется только свободное ядро :(
> т.е. потом возьмутся за него.
> ваш КЭПА чем systemd в этом помошник? Чем все остальные пакеты.
У Red Hat система init скриптов до systemd была явно сильно перетяжелённой. При чём сказывалось это и во всех случаях, где все её многогранные возможности были отнюдь не нужны. Так что можно сказать пересмотр в этой области был где-то даже весьма ожидаем...
> Запихать все в одну кучу чтобы было легче администрироватьУпрощение администрирования ещё куда ни шло, но устраивать большую кучу всего подряд для "повышения надёжности"...
Послушал пять минут и понял, как же вовремя я из всего этого администрирования ушёл :)П.С. пожелание тем кто работал над пособием: проработайте обсуждаемые вопросы и набросайте тезисы ПЕРЕД записью. (тяжело слушать постоянные затыки и обсуждения в эфире)
А в целом, тем кто вообще ничего не знает о systemd, пойдёт.
"Видеоурок" придумали модераторы опеннета - нет о нем ни слова по ссылке. А так общаются более-менее свободно и не читают монотонно с листа.Чуваки кстати делают неплохие в целом подкасты о Linux. Слушал пару раз на рподе.
Ну и произношение же у них... "Таргеты" вместо "целей" - это ещё туда-сюда, но произносить sysvinit как "сисвынит" вместо "сис-файв-инит".Странные ребята... Снимают "Шоу". А тезисы не проработали. Слушать грустно. Вместо того, чтобы структурированно рассказать материал, льют воду и машут руками.
Без англосаксов, патриотов и граммарнаци опеннет рунет представить нельзя.
Была когда-то такая хорошая черта у людей - они готовились к выступлениям: подбирали материал, работали над дикцией, перед тем, как выступать на камеру или перед публикой, предварительно прорабатывали выступление. Только самые лучшие, с многолетним опытом, решались выступать без подготовки. И мы, старшее поколение, привыкли к качественной подаче информации, нас избаловали.А современное поколение, выросшее на фейсбучных "себяшечках" (селфи), стоя апплодирует любому прыщу заснятому в полутьме на вебкамеру и показанному публично.
Теперь даже программируют также - сначала начинают всех учить, обсирая всех кто был до них, публикуя "обучающие" ролики на ютубе, потом, чтобы доказать свою правоту, начинают писать "правильные" подсистемы линукс, переворачивая всё с ног на голову, а уж потом начинают изучать программирование, параллельно разрабатывая "новый" язык программирования.
Дайте ссылку на ваши работы, пожалуйста.
Дык, все мои потуги и канули в процессе вечного перерождения опенсорсных проектов. Революций я не устраивал, системб и импульсаудио не писал, голой жопой в ютубе не маячил. Что Вам предоставить? IP адреса серваков и раб. станций, которые я обслуживал? Файлы озвучки? Переводы? Чертежи? Программы для ЧПУ и всяких там Симатиков? Жизнь нереволюционера скучна и однообразна. А с возрастом организм начал мстить за вечную гонку, так что... Да, я злой.
А, "сначаладобейся"..
Ссылку вам легко даст кто нибудь типа Цукерберга, какой нибудь великий разработчик одной из великих, нужных и модных современных "технологий". Который всего добился сам. Ну и еще родился внуком какого-нибудь Рокфеллера.
А есть просто инженеры, которые в своей области ответственности решают задачи и делают так, чтобы все работало. Но их в новостях не покажут. А за ссылка на работы для многих может быть просто нарушением контракта. Или невозможна по причине специфики проекта.
Ничего нового. Обычные хейтеры очень не любят говорить о своих заслугах - в первую очередь потому, что их нет. И приправляют это размышлениями о злой жизни, судьбе великих, и как делать нельзя. Бабки-возле-подьезда-стайл.Вообще не понимаю причем здесь столько соплей? Как будто филиал женского форума. Не нравится - возьми и сделай круче, так чтоб запонтоваться на весь район. К чему эти нежности и драмы?
Авторам - больше хардкора. Потомушто через пару лет никто не вспомнит что такие были на свете. Идея нужная, спору нет, но классных видеоканалов о линуксе с опенсорсом на русском просто тупо нет. И без классных харизматичных ведущих с интересной веселой тематикой их не будет еще долго. С другим контентом та же фигня.Ютуб - огромная аудитория. Почему бы не сделать классный популярный канал о линуксе с юзкейсами от школьников до инженегров? Есть же такие по гейфонах, винде, играх. Привлечь школоту, студентноту, пусть занимаются делом вместо дрочки в доту. даже подкинуть немного баксов на это готов.
Ффух, выдохнул.
> такие были на свете. Идея нужная, спору нет, но классных видеоканалов
> о линуксе с опенсорсом на русском просто тупо нет. И безПопалась цитата на совершенно другом форуме по другой теме, но так подходит: "Просто печально, что люди перестают читать книги, документацию, руководства... а пытаются освоить новые знания по американской методике: через YouTube и комиксы."
По системд много документации в сети, вики на том же альте, арче, дебиане, прочих.> Ютуб - огромная аудитория. Почему бы не сделать классный популярный канал о
> линуксе с юзкейсами от школьников до инженегров? Есть же такие по
> гейфонах, винде, играх. Привлечь школоту, студентноту, пусть занимаются делом вместо дрочки
> в доту. даже подкинуть немного баксов на это готов.Баксы тут не помогут. Фанаты доты будут дальше пялиться в свою доту, они просто не увидят что-то еще, потому что не будут искать этого. Инженер найдет документацию и статьи по тематике. А школьников должна научить школа. Хотите массово внедрить какие-то знания - тогда вам нужно массовое образование. Когда СССР начало индустриализацию, вопрос решили именно так - открыли кучу рабочих факультетов. Мотивировали людей на гос. уровне. И люди массово освоили необходимые навыки.
Это вы неплохо провели параллель с программированием. Залудили черновую "альфа"-версию, и выкатили её в паблик, полагая что так и надо.
Надёжность "надёжность за счёт интеграции и более тесного взаимодействия" не повышается. Надёжность повышается как раз за счёт изоляции.
> Надёжность повышается как раз за счёт изоляции.Исторически инит скрипты на надежность клали с прибором, начиная от отсутствия элементарного рестарта сервиса и заканчивая тотальным покладанием на коды ошибок и полным отсутствием логгинга при обломе запуска сервиса.
> Исторически инит скрипты на надежность клали с прибором, начиная от отсутствия элементарного
> рестарта сервиса и заканчивая тотальным покладанием на коды ошибок и полным
> отсутствием логгинга при обломе запуска сервиса.у меня логгируют, те что должны это делать, и ошибки обрабатывают. И рестартуют те что должны. Некоторые датируются 2005 годом, некоторые 2001. Вы видимо кактусов наелись.
> Исторически инит скрипты на надежность клали с приборомНе используйте дистрибутивы, где всё так плохо. А в приличных инитскрипты написаны с применением головы и функций, задействующих logger. И если надо сервис перезапускать вслепую, а не разбираться -- то есть monit, который хотя бы напишет "тут сервис A за B минут упал C раз, я его оставляю как есть, а вы всё же посмотрите".
Сколько уже можно детского FUD?
видео-учебники - это тренд, да :( уж как я лоялен к systemd, но видео-уроки не нужны.
> видео-учебники - это тренд, да :( уж как я лоялен к systemd,
> но видео-уроки не нужны.Видео-уроки нужны и полезны, не нужны те, кто необоснованно считает себя "профи"
> Видео-уроки нужны и полезны,Для тех, кто читать не умеет?
Для глухих по ссылке есть текстовая версия. Если что.
Умеющий читать не пойдет по ссылке, которая называется "Видео-урок". С каких пор медиа-приложения к докладу идут во главе угла? В вузах дипломы все еще на бумаге или тоже fullhd скриншоты на проекторе можно _вместо_ бумажного документа?
systemd - это все яйца в одной корзине, для повышения надёжности и удобства.
еще в школах и вузах на каждом заборе осталось навязать для полного кайфа
"etc" - "этк"япроставыпал
> япроставыпалОк, а как они скажут /usr/lib/NetworkManager/nm-pptp-auth-dialog - мне уже просто интересно :).
Ага. Вот видеоуроков по этому чуду только и не хватало.
> dbus-org.fedoraproject.rolekit1.serviceи т.д.
ну пц., вот этих гигантских е..ых названий файлов так и не хватало для удобного инита.
>> dbus-org.fedoraproject.rolekit1.service
> и т.д.
> ну пц., вот этих гигантских е..ых названий файлов так и не хватало
> для удобного инита.Откройте для себя bash-completion? Имена сервисов, таргетов и проч. нормально дополняются.
оно сделано через задницу и лагает. Более-менее нормально дополняются только пути.
> оно сделано через задницу и лагает.Ну тогда печатайте руками, если так быстрее. А у меня автодополнение неплохо работает даже на сравнительно хилом ноуте, не говоря уж о десктопе. Оно конечно может подумать с полсекунды на каких-то особо хитрых комбинациях, но полсекунды на набор длинной финги не идет ни в какое сравнение с печатью оной лично...
Господи, что это? Кто выдержит 1,5 минуты - медаль. Что за "АА.. в частности", "после этого эээ, нет, не совсем".. Теперь я понимаю, откуда же появился зизтенти...
+, основной шумогенератор похоже вообще нифига не шарит, не конкретно в systemd, а вообще.
Похоже, по мнению авторов видео основная целевая аудитория systemd не осилит печатный текст, поэтому для них специально "запилили" видео.
Осталось дождаться платных курсов и платных сертификационных экзаменов. Да, и про мост вэльюэбл партнерс не забыть бы.
"Пипл хавает"
(Алибасов, Бари Каримович)
На современных машинках, за полтора часа можно собрать всю систему gentoo с нуля excluded systemd ;) Какое-то МАЛЕНЬКОЕ не соответствие по времени.
Да. Потому что можно за 20 минут.
это же будет бразильский сериал "systemD"
> это же будет бразильский сериал "systemD"Бразильский сериал нонче в дебиане. "Расставание со слезами на глазах"
Отлично. У меня, домашнего ламероида, оно работает и обновляется без моего вмешательства уже пару лет и даже пережило клонирование на второй компьютер. Погляжу хоть теперь наглядно, что там внутрях.
ЕТК и СЕРВАЙС просто убили! :)
Ну сейчас все хейтеры ознакомятся, поймут что вещь интересная и полезная и наверно не будут писать шаблонные и необоснованные жалобы на опеннете... Да?
> Ну сейчас все хейтеры ознакомятся, поймут что вещь интересная и полезнаяСюда как-то набегали такие же голубоглазые(r) белокурые(tm) виндостуденты, искренне уверенные, что аборигены виндушечку в жизни не видали, вот и мучаются со своими кривыми линуксами, где даже metro нет...
То, что люди с опытом в десятки лет видали и винду тоже, а некоторые здесь её знают гораздо лучше новоиспечённых "профи" -- им оказывалось сюрпризом.
Вспомнилось почему-то.
> Ну сейчас все хейтеры ознакомятся, поймут что вещь интересная и полезнаяОзнакомился. Убедился, что это даже ненужнее, чем я думал.
Растет новое поколение сисадминов, которое не умеет читать и печатать на клавиатуре.
Бубеныть, пофигу. В убунте и хромос, которые реально везде, там upstart, вот по нему и имеет смысл и вообще полезно уроки записывать. А systemd - это федоровские лабораторные эксперименты. Зачем это все форсить-то постоянно?
Спросите у каноникал и гугль зачем они форсят системд вместо своего распрекрасного апстарт.
Космонавт все отложил до 16го года, как минимум. Про Гуг и его форсинк системды в первый раз слышу.
Космонавт уже в 14.10 впилил, но не по умолчанию, с 15.4 будет дефолтом, потому апстарт не таким восхитительным уродился чтобы его дальше держать против течения дебиана. А в ЛТС 14.4 ясен пень никто не стал менять отлаженый апстарт на ещё сырой системд.
Мечтать не вредно, оно кусками и в 12.04 было. И от-того, что появится возможность свичнуться на системд( возможно в апреле след года) никто апстарт не выбрасывает, как минимум до следующего LTS.
> Мечтать не вредно, оно кусками и в 12.04 было. И от-того, что
> появится возможность свичнуться на системд( возможно в апреле след года) никто
> апстарт не выбрасывает, как минимум до следующего LTS.В 14.10 уже есть возможность штатно переключиться на systemd. Апстарт сменят на системд как минимум за один релизо до ЛТС, а то не комильфо выкатывать необкатаную штуку в ЛТС, хотя космонавту не привыкать, да.