В ходе работ по улучшению поддержки системного менеджера systemd в качестве init-процесса начального RAM-диска (initrd), разработчики Кей Сайверс и Гарольд Хойер столкнулись (https://plus.google.com/108087225644395745666/posts/H9CFBQLG... с интересным и по-своему курьезным фактом — при использовании initrd, суммарное время инициализации ядра и initrd оказалось примерно на 10% меньше, чем время инициализации ядра без initrd.
Начальный RAM-диск (http://ru.wikipedia.org/wiki/Initrd) (initrd) представляет собой специализированную файловую систему, которая используется ядром на стадии начальной загрузки. Основная задача initrd — обеспечить монтирование жизненно важных файловых систем: корня и /usr. В наиболее простых ситуациях (локальные дисковые разделы) данная работа может быть проделана и ядром, однако в случае использования для этих разделов специфическим механизмов (LVM, RAID, multipath, шифрование, NFS), initrd является наиболее простым и гибким решением. Также он может оказаться полезен в качестве аварийно-восстановительной системы, предоставляя администратору средства, необходимые для исправления ошибок при монтировании ключевых системных разделов.
Традиционно считалось, что отказ от initrd должен неизбежно привести к увеличению скорости загрузки. Однако, при использовании в качестве init-процесса initrd systemd, результат получился неожиданным и парадоксальным: ядро в сочетании с initrd отрабатывали быстрее, чем ядро без initrd. Наиболее вероятная причина состоит в том, что при загрузке без initrd ядро выполняет вызов wait_for_device_probe(), ожидая завершения инициализации всех периферийных устройств. В то время как при использовании initrd с systemd, загрузка продолжается сразу после инициализации необходимых устройств (т.е. носителей корня и /usr).
Асинхронная архитектура systemd, в отличие от классической синхронной, позволяет не задерживать процесс загрузки на ожидание устройств, которые не требуются на данном этапе. В зависимости от аппаратной конфигурации системы, эта задержка может сильно отличаться: например, встроенный в ноутбук 3G-модем без SIM-карты задерживает загрузку на 5 секунд, а сервер с тысячами физических дисков и/или логических томов может потерять несколько десятков минут, опрашивая каждое блочное устройство на предмет наличия на нем файловой системы.
Стоит отметить, что в обсуждении (https://plus.google.com/108087225644395745666/posts/H9CFBQLG... один из разработчиков приводит довольно простой патч (http://git.fenrus.org/git/?p=packages/kernel.git;a=blob;f=bo... который теоретически должен исправить эту проблему, путем перевода данной операции в ядре на асинхронный режим. К сожалению, пока отсутствуют результаты измерений, которые бы позволили судить об эффективности такого исправления.
В дополнение, несколько других, более коротких новостей от проекта systemd:
- Разработчики systemd и Arch Linux Том Гундерсен и Дейв Рейзнер обеспечили (https://plus.google.com/114015603831160344127/posts/RtPgrezU... поддержку systemd в качестве init-процесса initrd при использовании стандартного для Arch генератора inird — mkinitcpio (в то время, как упомянутая выше работа Сайверса и Хойера акцентируется на dracut, стандартном initrd-генераторе Fedora/RHEL и Mageia/Mandriva).- Разработчик Arch Linux и SDDM (http://www.opennet.me/opennews/art.shtml?num=36449) Андреа Скарпино представил (https://plus.google.com/104652450278570828775/posts/BjcLZyDL... библиотеку libsystemd-qt (https://github.com/ndr/libsystemd-qt), упрощающую обращение к функциям systemd из программ на базе фреймворка Qt. В качестве примера использования библиотеки приводится простая программа ksystemd, позволяющая просматривать состояние различных системных юнитов. В целом, проект направлен на улучшение взаимной интеграции systemd и KDE.
- Разработчики пользовательского окружения Enlightenment обеспечили (http://git.enlightenment.org/core/enlightenment.git/commit/?... поддержку использования systemd в качестве системы инициализации сеанса. Запуск пользовательского сеанса в десктоп-окружении во многом аналогичен загрузке системы, что позволяет использовать для решения обеих этих задач один и тот же механизм, с минимальной адаптацией. Ранее, в силу сложившейся в эпоху SysV init традиции неоднократно дублировать и реализовывать заново уже существующую функциональность, каждое десктоп-окружение предлагало свою собственную систему инициализации сеанса. Замена множества собственных реализаций на общий стандарт должна упростить жизнь разработчикам DE и позволит им сконцентироваться на более актуальных задачах.
- Опубликованы видеозаписи докладов сотрудника компании Wargaming (известной своей игрой World of Tanks) Максима Мельникова, одного администраторов инфраструктуры серверов World of Tanks. В первом докладе (https://www.youtube.com/watch?feature=player_embedded&v=uAzV... «Зачем нам systemd», кратко рассматриваются ключевые преимущества systemd, полезные для системных администраторов и отсутствующие в других решениях. Во втором докладе (https://www.youtube.com/watch?feature=player_embedded&v=gDEi... обсуждаются достоинства механизма Journal и разбирается практический пример его использования. Доклады примечательны тем, что тема использования systemd впервые затронута на русскоязычной конференции разработчиков и пользователей Linux ((LVEE 2012 (http://lvee.org/ru/reports/materials_lvee_2012)).
<center>
<iframe width="640" height="360" src="http://www.youtube.com/embed/uAzVsVAVbEU?rel=0" frameborder="0" allowfullscreen></iframe></center><center>
<iframe width="640" height="360" src="http://www.youtube.com/embed/gDEiCsjA1mk?rel=0" frameborder="0" allowfullscreen></iframe></center>URL: https://plus.google.com/108087225644395745666/posts/H9CFBQLG8S8
Новость: http://www.opennet.me/opennews/art.shtml?num=36611
Норм.
Продолжаем анонировать на время загрузки?
В тексте есть намек на крайнюю ситуацию: "Проблема в датацентре устранена, сервера уже загружаются и часа через полтора, опросив всю периферию, наконец загрузятся".
Хватит уже идеопатировать, какие полтора чяса? проверка одного диска в 3тб длиться дольше будет чем опрос 26 дисков. И да лучше знать сразу при загрузке что у тебя траблы с винтами чем потом ковырять логи.
> Хватит уже идеопатировать, какие полтора чяса? проверка одного диска в 3тб длиться
> дольше будет чем опрос 26 дисков. И да лучше знать сразу
> при загрузке что у тебя траблы с винтами чем потом ковырять
> логи.А при чем здесь траблы с винтами?
> А при чем здесь траблы с винтами?мозг включи, ага.
Как минусуют на предложение влючить мозг! Прям красота...
> Как минусуют на предложение влючить мозг! Прям красота...Естественно. Они считают, что включать мозг - "несовременно". Мозг должен включить им systemd... когда посчитает нужным... "асинхронно"
> при загрузке что у тебя траблы с винтами чем потом ковырять логи.А давайте всем дискам fsck при старте делать по этому поводу, да? Всем 26. На 3 Тб. И полную проверку поверхности. Чтоб уж наверняка. И пусть весь мир подождет!
да, лучше бы сделали on-line проверку fs как в FreeBSD и не парились
> да, лучше бы сделали on-line проверку fs как в FreeBSD и не парилисьКроме деградации перфоманса дисков на хзсколько часов :)
Советую Вам когда-нибудь заглянуть в BSD-ый lost+found на разделе с UFS с хваленым soft updates, и придти в ужас, если сервер несколько раз ребутали резетом.Нет уж, на фре только ZFS!
Правильно. там нет lost+found. Соответственно некуда смотреть и в ужас не придешь.
> Правильно. там нет lost+found. Соответственно некуда смотреть и в ужас не придешь.Что бы появился, ребутните пару раз сервер под настоящей(не локалхостовой) нагрузкой
> да, лучше бы сделали on-line проверку fs как в FreeBSD и не
> парилисьВот уж не надо, я с этим ужасОм несколько лет мучался. Хуже был только ntfs
Пурга, боец. Читай устав - он кровью писан. Такие проблемы решаются по другому, и если датацентр сдохнет ... никто в мире кроме NOC'а и товариша полковника - и не узнает, даже TCP сессии не порвуться.А ты (салага!) предлагаешь суетиться и сучить - а это не наши методы! Пи^W как там ныне положено - АМЕН!
Иллюстрация по теме "сорванные башни".
Там ананировать не на что, если бы хоть ощутимый эффект был. Тонны кода, документации, холиваров, а на выходе -2 секунды от 20. Я не воодушевлен.
> Там ананировать не на что, если бы хоть ощутимый эффект был. Тонны
> кода, документации, холиваров, а на выходе -2 секунды от 20. Я
> не воодушевлен.Тонны документации - уже офигенно полезных выход. Особенно по сравнению со всякими SysV init и OpenRC, где чтобы понять назначение скрипта, необходимо читать его код. А в systemd каждый чих документирован, и про каждый чих делается подробная запись в логи.
Ещё, знаешь, названия скриптов помогают %)
> Ещё, знаешь, названия скриптов помогают %)Если бы названия всегда помогали, программа man так бы никогда и не появилась. И info тоже.
> Ещё, знаешь, названия скриптов помогают %)Спасибо, видел я что обычно творится в таких скриптах. И лучше я буду читать простой конфиг на 5 строк чем то что там нынче навалено. Не в обиду, но в половине инитовских скриптов почему-то оказывается лютейший гогнокод писаный на коленке каким-то укуренным бабуином. Например, константы размазанные по всей трехстраничной портянке вперемешку с логикой - стандартное состояние дел.
Ты забыл добавить, что этот говнокод между дистрибутивами, к тому же, обычно еще и непереносим. И поэтому майнтенеры каждого из них занимаются сочинением своих ламповых инит-говняшек.
> Ты забыл добавить, что этот г внокод между дистрибутивами, к тому же, обычно
> еще и непереносим. И поэтому майнтенеры каждого из них занимаются сочинением
> своих ламповых инит-г вняшек.Может, вы просто скрипты ни писать ни читать не умеете, м? Оба причем?
> Может, вы просто скрипты ни писать ни читать не умеете, м? Оба причем?Осталось еще добавить что зато вот вы - Д`Артаньян :).
> И лучше я буду читать простой конфиг на 5 строкА если он не сдюжит работать как надо -- пойдёте читать исходники systemd?
> Тонны документации - уже офигенно полезных выход. Особенно по сравнению со всякими
> SysV init и OpenRC, где чтобы понять назначение скрипта, необходимо читать
> его код. А в systemd каждый чих документирован, и про каждый
> чих делается подробная запись в логи.Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией? И каждый чих документировать не нужно - он самим скриптом документирован уже.
А в systemd приходится даже чихи, при чем - каждый! - документировать. При чем следуеи учитывать, что история учит только одному - история ничему не учит. Это я к чему - исторически сложилось так, что доступная документация на пару-тройку версий отстает от быстро развивающейся программы. А уж найти более быстро развивающуюся программу, чем systemd, задачка не из простых!
> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной
> документацией? И каждый чих документировать не нужно - он самим скриптом
> документирован уже.Вы полагаете, это нормально, когда вместо чтения man-страницы приходится читать код (причем отнюдь не три строчки, и написан он далеко не всегда читабельно)?
> А в systemd приходится даже чихи, при чем - каждый! - документировать.
В SysV init, по хорошему, тоже нужно. Но на это просто забивают, отбрехиваясь заклинаниями про "прозрачность".
> При чем следуеи учитывать, что история учит только одному - история
> ничему не учит. Это я к чему - исторически сложилось так,
> что доступная документация на пару-тройку версий отстает от быстро развивающейся программы.Не знаю, у каких таких программ она отстает, а у systemd изменения в код и документацию идут либо в одном коммите, либо в двух подряд.
> > Зачем нужны тонны документации, если сам скрипт служит себе же самой полной
> > документацией? И каждый чих документировать не нужно - он самим скриптом
> > документирован уже.
>
> Вы полагаете, это нормально, когда вместо чтения man-страницы приходится читать код (причем отнюдь не три строчки, и написан он далеко не всегда читабельно)?ну для большинства и букварь поначалу нечитабелен, а с опытом - вполне себе ;-)
> ну для большинства и букварь поначалу нечитабелен, а с опытом — вполне
> себе ;-)до сих пор не могу спокойно читать. как увижу «мама мыла раму» — так возбуждаюсь сразу.
> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией?По опыту чтения таких скриптов - чаще всего он служит документацией по теме "быдлокодинг на шелл, или как не надо писать скрипты инициализации".
>> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией?
> По опыту чтения таких скриптов - чаще всего он служит документацией по
> теме "быдлокодинг на шелл, или как не надо писать скрипты инициализации"Чтение исходников сисемд, несомненно, обогатит ваш опыт, но вряд ли изменит ваши выводы.
И таки да, чтение документации в каких то простых случаях может заменить чтение исходников.
> Чтение исходников сисемд, несомненно, обогатит ваш опыт, но вряд ли изменит ваши выводы.Если я суюсь в систему инициализации, у меня как правило цель - новый кастомный демон запустить. А вовсе не все исходники в мире перечитать. Чем проще это делается - тем лучше моя жизнь. Это так сложно понять? Вот написать 5 строчек в конфиг - это явно проще чем вкуривать в трехстраничные скрипты писанные левой пяткой какого-то индивида.
> И таки да, чтение документации в каких то простых случаях может заменить чтение исходников.
И таки да, в 99% случаев это именно простые случаи и будут. Ну, запуск/останов демона. Ну по некоторым критериям, например "сеть появилась!". Ну под неким юзером. Ну с неким приоритетом. Ну перезапуск, если он упал. Совершенно стандартные задачи. И вот это вот в sysv init приходится довольно густо докостыливать. В то время как в сабжеобразных системах инициализации это пяток строк конфига и более нифига.
> Если я суюсь в систему инициализации, у меня как правило цель -
> новый кастомный демон запустить. А вовсе не все исходники в мире
> перечитать. Чем проще это делается - тем лучше моя жизнь. Это
> так сложно понять? Вот написать 5 строчек в конфиг - это
> явно проще чем вкуривать в трехстраничные скрипты писанные левой пяткой какого-то
> индивида.тут важно определиться - Вы в роли юзера или админа.
Если юзера - то все понятно, хочется чтобы "все искаропки", ну и что-то прикрутить простое и понятное с помощью отвертки была возможность.
Ежели админа - тогда непонятно нежелание чтения скриптов - Вам не нравится изучать, как система устроена? Как же Вы тогда хотите получить знания о ее работе? Документация зачастую неполна и неточна...
В отличие от скриптов, чтение исходников системд и не требуется. Здесь требуется только прочитать что добавлять в конфиги. Которые, как я понимаю, более менее логичны и единообразны, в отличие от длинных портянок скриптов с кучами переменных и циклов
ага. логичны и единообразны. с кучей ключей типа «запустить, если есть файл abc.» «запустить, если есть файл abc и сегодня новолуние.» «запустить, если…»вот вся эта штука называется «командный язык». и он — СЮРПРАЙЗ! — уже давно есть. shell. но у Инноваторов NIH в тяжелейшей форме, поэтому вместо sh и набора утилит они делают монстра systemd и набор условных команд. чтобы администраторам надо было знать И sh, И systemd. а раньше одного sh хватало.
>> Зачем нужны тонны документации, если сам скрипт служит себе же самой полной документацией?
> По опыту чтения таких скриптов - чаще всего он служит документацией по
> теме "быдлокодинг на шелл, или как не надо писать скрипты инициализации".а никто и не обещал в этих скриптах примерных учебных пособий.
с опытом, когда умеешь незадумаваясь читать разный по стилю и качеству код, уже понимаешь, что ранее отвратное - теперь просто особенность написания.
ну а совсем уж ужасные или опасные места сам переписываешь с матюками и патчами - опенсурс же
> Тонны документации - уже офигенно полезных выход.Это пока её не *приходится* читать от и до. Скрипты в этом плане куда меньше претендуют на выедание мозга (если читатель не виндузятник рееструс вульгарис, а человек с пониманием шелла).
> А в systemd каждый чих документирован, и про каждый чих делается подробная запись в логи.
Вот только в реальной работе не помогает, а так почти не соврали, да.
> этом плане куда меньше претендуют на выедание мозгаЭто, знаете ли, очень от скрипта зависит. Пишут их разные люди. Хотя временами возникает ощущение что пишут эти скрипты таки не люди. А инопланетяне, укуренные бабуины и прочие тушканчики. Чисто глядя на тот код который там встречается. Где константы (при том верные только для системы автора) размазаны равномерным слоем по трехстраничной портянке и прочие подобные "прелести".
Покажи на примере debian или rhel. В то что создатели маргинальных дистров могут придумать что угодно я и так верю, были же долбодятлы, которые все на php хотели переписать.
Вообще большой размер отдельных инит-скриптов связан с нестандартными действиями и systemd здесь не поможет. Стандартные действия у debian и rhel уже оформлены в шелловые функции и писать свой собственный start-stop-daemon в большинстве случаев смысла нет.
> Покажи на примере debian или rhel.Начались виляния попой. Вот есть прога. Допустим в репах ее нет. Надо демон запустить. Обнаруживаем что там или совсем нет скрипта и надо самому писать. Или там есть черти-какой гогнокод, валидный только для системы автора. И так и сяк - много гемора. Написать 5 строк в конфиг - намного проще. И для более-менее типового процесса демона их будет выше крыши, все дела.
> В то что создатели маргинальных дистров могут придумать что угодно я и так верю,
> были же долбодятлы, которые все на php хотели переписать.Вообще-то гунявые скрипты встречались и просто в программах. Которые дебианщики или рхеловцы не удосужились запакетировать совсем. Ну или скриптов может вообще не быть. Спорный вопрос что лучше: гунявые скрипты или никаких вообще.
> Стандартные действия у debian и rhel уже оформлены
При том у каждых по своему.
> Начались виляния попой. Вот есть прога. Допустим в репах ее нет. Надо
> демон запустить. Обнаруживаем что там или совсем нет скрипта и надо
> самому писать. Или там есть черти-какой гогнокод, валидный только для системы
> автора. И так и сяк - много гемора. Написать 5 строк
> в конфиг - намного проще. И для более-менее типового процесса демона
> их будет выше крыши, все дела.Дело в том, что это еще нужно разобраться, кто "виляет попой". Вам предложили два основных подхода к реализации стартовых скрипов. Если этого мало, есть LSB. Со скриптами, оформленными в соответствии с LSB проблемы иногда наблюдаются только у "маргинальщиков", которые LSB не поддерживают.
И да, если уж на то пошло, можно взять шаблон стартового скрипта и заменить в нем одну строчку - путь к программе. Если программа писалась в соответствии со стандартами - она запустится и будет работать. Если же автор программы - чудак, не желающий иметь ничего общего со стандартами, то systemd тут мало чем поможет, так как написать unit для такой программы может оказаться сложнее, чем стартовый скрипт - отладить его значительно сложнее.>> Стандартные действия у debian и rhel уже оформлены
> При том у каждых по своему.Еще раз повторяю - в гугл по термину LSB (Linux Standard Base).
А если автор не желает писать в соответствии со стандартами (яркий пример - Ваш любимый герой Поттеринг!), то тут ни systemd, ни оформление каких-то магических unit’ов в 5 строчек не поможет.
> Это, знаете ли, очень от скрипта зависит. Пишут их разные люди. Хотя
> временами возникает ощущение что пишут эти скрипты таки не люди. А
> инопланетяне, укуренные бабуины и прочие тушканчики.Что мешает "сказочнику" написать как надо и выложить?
Если ты не можешь написать, то как ты можешь оценивать достоверно?
Ну и если никто не улучшил, логично что это г никому кроме тебя не надо. А тут знаешь ли безотносительно из под чего это редкое глюкавое г у тебя будет запускаться. Так то
> Что мешает «сказочнику» написать как надо и выложить?ну, иногда просто лень. «да, это надо бы переписать, и при вот таких вот обстоятельствах его заглючит, но… вот когда заглючит, тогда и перепишу. а пока пусть так ковыляет.» и оно годами так ковыляет.
> вот когда заглючит, тогда и перепишу.Ситуация знакомая до боли. Но я не вижу чем systemd может помочь в данной ситуации. Разве что тем, что на systemd, потенциально, глюки полезут раньше. Синтаксис скриптов /bin/sh устоялся ещё во времена Наполеона или где-то около. А вот в устойчивость опций systemd мне не очень верится.
так и я о том же.
>> Тонны документации - уже офигенно полезных выход.
> Это пока её не *приходится* читать от и до. Скрипты в
> этом плане куда меньше претендуют на выедание мозга (если читатель не
> виндузятник рееструс вульгарис, а человек с пониманием шелла).А зачем мне перечитывать десятки реализаций обработки PID-файлов различной степени корявости на шелле, если в системд это делается одной строкой в конфиге, которая везде работает одинаково и эта работа описана в мане?
В debian/rhel это тоже делается одной строкой. Вот только при желании вы можете прочитать что стоит за этой строкой имея знания только шелл.
> В debian/rhel это тоже делается одной строкой. Вот только при желании вы
> можете прочитать что стоит за этой строкой имея знания только шелл.В альте скомбинировано (т.е. rh-style в целом, но с применением start-stop-daemon).
> В debian/rhel это тоже делается одной строкой. Вот только при желании вы
> можете прочитать что стоит за этой строкой имея знания только шелл.То, что в debian и rhel есть готовые функции для стандартных действий (кстати, часто в их реализации залезаешь?) не отменяет наличия кучи инит-скриптов, авторы которых решили изобрести велосипед.
то, что в libc есть готовые функции для стандартных действий (кстати, часто в их реализации залезаешь?) не отменяет наличия кучи сишнософта, авторы которого решили изобрести велосипед.поэтому — по твоей же логике — си следует выкинуть подальше, и вместо него сделать язык, у коготорого пять команд — разные варианты вывода приветмира, а шестая — вызов внешней программы на древнем си, когда приветмиров не хватило. и этот язык должен стать основным языком разработки системного софта.
если до тебя и в таком виде не дошло, то ты безнадёжен.
> то, что в libc есть готовые функции для стандартных действий (кстати, часто
> в их реализации залезаешь?) не отменяет наличия кучи сишнософта, авторы которого
> решили изобрести велосипед.Много ли сишных программ, в которых используются свой аллокатор вместо malloc просто потому, что автор не знал о его существовании? Мне так не кажется.
А вот в инит-скриптах подобное излишнее велосипедостроение на каждом шагу.> поэтому — по твоей же логике — си следует выкинуть подальше, и
> вместо него сделать язык, у коготорого пять команд — разные варианты
> вывода приветмира, а шестая — вызов внешней программы на древнем си,
> когда приветмиров не хватило. и этот язык должен стать основным языком
> разработки системного софта.Твою аналогию можно было бы принять, если бы 99% используемых сишных программ только бы и делали, что выводили "Привет мир". Однако, это не так.
есть информация о том, что 99% инит-скриптов именно «выводят приветмир»? где почитать исследование?я даже не буду при этом требовать, чтобы там всенепременно были велосипеды, потому что авторы не знают про стандартные библиотеки функций для инит-скриптов, которые в дистрибутивах таки есть. и не буду требовать доказательств того, что авторы именно не знали о. давай начнём с доказательства первого утверждения, остальное потом.
> есть информация о том, что 99% инит-скриптов именно «выводят приветмир»? где
> почитать исследование?Просто феерично. Сначала ты говоришь о том, что замена инит-скриптов, выполняющих запуск/останов демонов в большиснтве случаев по одной той же схеме, на конфиги равнозначна замене универсального языка Си на язык, только и могущий, что выводить "привет мир", что уже является бредом. А когда я тебе указала на некорректность сравнения однообразных инит-скриптов и разнообразных программ, написанных на Си, то почему-то высплыла необходимость доказательства только что рожденного твоим нездоровым разумом утверждения о том, что 99% инит-скриптов выводят "привет мир". До каких пор ты собираешься нести бред?
> Много ли сишных программ, в которых используются свой аллокатор вместо malloc
> просто потому, что автор не знал о его существовании?Трудоёмкость выполнения выберите всё-таки сопоставимую, проводя аналогию.
>> Много ли сишных программ, в которых используются свой аллокатор вместо malloc
>> просто потому, что автор не знал о его существовании?
> Трудоёмкость выполнения выберите всё-таки сопоставимую, проводя аналогию.Аналогия моего оппонета "специализированные скрипты - произвольные программы" изначально является бредом и развивать ее я не собираюсь.
>>> Тонны документации - уже офигенно полезных выход.
>> Это пока её не *приходится* читать от и до. Скрипты в
>> этом плане куда меньше претендуют на выедание мозга (если читатель не
>> виндузятник рееструс вульгарис, а человек с пониманием шелла).
> А зачем мне перечитывать десятки реализаций обработки PID-файлов различной степени корявости
> на шелле, если в системд это делается одной строкой в конфиге,
> которая везде работает одинаково и эта работа описана в мане?Не могу понять, о чём вообще спор. Есть несколько ситуаций, которые, похоже, перемешались в голове у спорящих:
1) Установили софтину, надо стартануть. Если при установке мы не получили уведомлений о том, что надо что-то особенное сделать - правим конфиг (если надо; документацию по самой софтине ведь читать в любом случае надо, правильно?) и стартуем - для этого у нас и скрипт/юнит. Разницы между systemd и прочим на этом этапе НЕТ.
2) Софтина таки не стартует. В случае rc-скриптов читаем ошибки на stderr (возможно, запуская заново с какой-нибудь волшебной опцией - тут согласен, неудобно, ибо ошибка может быть не постоянно возникающей) и смотрим в логи любой удобной программой. В случае systemd - смотрим в логи, ибо больше особо ничего не светит. Причём смотрим только теми средствами, которые systemd нам даёт - спасибо дяде Поттерингу за бинарную свободу выбора.
3) Нам надо написать собственно скрипт/юнит для запуска. Тут всё зависит от конкретного случая - некоторые системы rc-скриптов просты, некоторые не очень. Зато и отлаживать rc-скрипты заметно проще. Плюс: вменяемый админ в любом случае умеет управляться с шеллом, а, следовательно, в случае rc-скриптов не приходится изучать лишний (именно лишний!) декларативный язык.
В общем, преимуществ у systemd именно по части запуска сервисов - только _возможность_ их асинхронного запуска, с сомнительным преимуществом в лишние несколько секунд аптайма.
Про остальные особенности systemd я лучше промолчу...
> В случае systemd - смотрим в логи, ибо
> больше особо ничего не светит.Systemd перенаправляет stderr в syslog/journald, при этом еще и показывая кусок, имеющий отношение к демону, при вызове systemctl status daemon.service
> Особенно по сравнению со всякими SysV init и OpenRC, где чтобы понять назначение скрипта, необходимо читать его код. А в systemd каждый чих документирован, и про каждый чих делается подробная запись в логи...аноним английский осилил, а юникс-шелл - нет...
Тоже думаю, что давно надо было включить Qt в systemd.
>В ходе работ по улучшению поддержки системного менеджера systemd.... загрузка с initrd оказалась быстрее загрузки без initrdА потом, в ходе работ по улучшению, они поймут, что набор отдельных скриптов на баше делает процесс загрузки более быстрым, гибким и настраиваемым.
Да. Это вброс.
> набор отдельных скриптов на башеЗа bash в init-скриптах нужно бить тяжёлым тупым предметом по голове, особенно когда файл начинается с «#!/bin/sh».
хе-хе! Один попался :)
> особенно когда файл начинается с «#!/bin/sh».А когда он начинается с «#!/sbin/runscript»?
>> особенно когда файл начинается с «#!/bin/sh».
> А когда он начинается с «#!/sbin/runscript»?Не знаю. Ни в Debian, ни в RHEL такой команды нет.
>>> особенно когда файл начинается с «#!/bin/sh».
>> А когда он начинается с «#!/sbin/runscript»?
> Не знаю. Ни в Debian, ни в RHEL такой команды нет.Да, это местечковый велосипед :)
> особенно когда файл начинается с «#!/bin/sh».согласен, раз нарвался на проблему:
сидел на центоси, там /bin/sh вызывал /bin/bash
перешел на демьяна и вдруг все мои инит-скрипты перестали работать (
оказалось в демьяне /bin/sh вызывает /bin/dash (Debian Almquist Shell (dash))
Ну и кто в итоге дураком остался?
> Ну и кто в итоге дураком остался?Поттеринг, конечно же.
>> особенно когда файл начинается с «#!/bin/sh».
> согласен, раз нарвался на проблему:
> сидел на центоси, там /bin/sh вызывал /bin/bash
> перешел на демьяна и вдруг все мои инит-скрипты перестали работать (
> оказалось в демьяне /bin/sh вызывает /bin/dash (Debian Almquist Shell (dash))Обычно правильные инит-скрипты сразу завязаны на какой-нибудь свой дистрибутивоспецифичный /etc/init.d/functions (куда вынесена часто используемая функциональность) и непортабельны оп определению, даже если шелл тот же самый.
> и непортабельны оп определениюОтчасти это так, поскольку в разных дистрибутивах по-разному смотрят на задачи конфигурирования и зачастую это имеет под собой основания. Вот только "как ни садитесь"...
> и зачастую это имеет под собой основания.А потом берешь с сайта авторов программу которой в репе не было или версия не та или что там еще. Там вроде как есть скрипт. Чпокс - не работает. Чпокс - там гогнокод. Чпокс - вагон допущений о системе, взятые из системы автора и размазанные по всей портянке. Получается что "висит груша - нельзя скушать". Во, блин, счастье - самому с нуля переписывать портянку или три страницы чужого гогнокода лопатить. Супротив конфига на пяток строк - разница совсем не в пользу портянки получается.
Может пнуть его для начала через 'dpkg-reconfigure dash'?
Или как там в Дебианах? RTFM же...
Однако ж и в #171 посмотреть.
Для начала, если для неинтерактивного шелла выбран dash, то наверное это зачем-то нужно.Лично /me тут совсем больших выгод не знает, но встряхнуть любителей использовать башизмы вместе с /bin/sh вещь неплохая. Хоть и поотваливалось кое-где ой...
Туым предметом надо бить тех, кто не осознает, что /bin/sh не обязан равняться /bin/bash.
> Туым предметом надо бить тех, кто не осознает, что /bin/sh не обязан
> равняться /bin/bash.sysvinit-проблемы :)
>> Туым предметом надо бить тех, кто не осознает, что /bin/sh не обязан
>> равняться /bin/bash.
> sysvinit-проблемы :)Да нет, проблемы "программеров", которые сначала чего-нибудь накодят, а потом говорят - "Да зачем нужны эти ваши стандарты?! Теперь будет вот так, я переписывать свою писанину ради сответствия стандартам не буду!"
Но в случае sysvinit эта проблема решается правкой одной-двух строчек. А вот в случае systemd - это генетическая проблема, не имеющая, как правило, простого и однозначного решения.
> Да нет, проблемы "программеров", которые сначала чего-нибудь накодят, а потом говорят -
> "Да зачем нужны эти ваши стандарты?! Теперь будет вот так, я
> переписывать свою писанину ради сответствия стандартам не буду!"
> Но в случае sysvinit эта проблема решается правкой одной-двух строчек.Не подскажете, как правкой одной-двух строчек заставить произвольно выбранный init-скрипт запускаться на любом дистрибутиве?
> запускаться на любом дистрибутиве?Никак. Более того - половина долбоклюев пишет эти портянки по принципу "у меня же работает?!". Да еще перемешав пути с логикой и прочая. Чинить за ними такой крап - на редкость отвратное занятие.
> Не подскажете, как правкой одной-двух строчек заставить произвольно выбранный init-скрипт запускаться на любом дистрибутиве?Если скрипт и дистрибутив LSB-совместимые, то особых проблем быть не должно. В иных случаях проще будет написать с нуля.
>> Не подскажете, как правкой одной-двух строчек заставить произвольно выбранный init-скрипт запускаться на любом дистрибутиве?
> Если скрипт и дистрибутив LSB-совместимые, то особых проблем быть не должно. В
> иных случаях проще будет написать с нуля.Ага. До первого "source /lib/lsb/init-functions", который, как оказывается, в дебиане не тот же самый, что и в centos. Вот и переписывают с нуля. И зачем, спрашивается?
> А потом, в ходе работ по улучшению, они поймут, что набор отдельных
> скриптов на баше делает процесс загрузки более быстрым, гибким и настраиваемым.
> скриптов на баше
> быстрым/0
>> скриптов на баше
>> быстрым
> /0Почитайте скрипты {ldv,legion}@altlinux и поучитесь писать без лишних форков. Естественно, если вместо read var < file использовать var=`cat file` (вот так, без кавычек даже) -- тормозить будет как детский трактор.
Младотурки, блин. Даже на ноль делить в школе не научились.
> Почитайте скрипты {ldv,legion}@altlinux и поучитесь писать без лишних форков.Я вот почитал факин ман на апстарт и научился писать ему джобы. Теперь оно и процессы перезапускает, и приоритет им ставит, и под нужным юзером пинает, etc, etc, etc. По нужным событиям и без лишних форков. И всего пяток строчек конфига на все про все. Вот это - хорошее соотношение efforts/results. Куда лучше упомянутых портянок на мое нескромное мнение. А если вдруг этого окажется мало - вот тогда уже и будем звать скриптопортянки. Только это надо в хорошо если 1% случаев.
"Если программисты настолько незрелые, то их поделиям нечего делать на моих системах" - ЛОР шагает ИРЛ.
Разработчики initrd: загрузка без systemd оказалась быстрее загрузки с systemd
через 10 лет, Леннарт научиться писать интерпретаторы и напишет свой баш и перепишет все на него.
Он command.com свой напишет, после чего в autoexec.bat можно будет положить скрипт инициализации.
> Разработчики initrd: загрузка без systemd оказалась быстрее загрузки с systemdА что, разработчики initrd и разработчики systemd - разве не одно и то же?
>> Разработчики initrd: загрузка без systemd оказалась быстрее загрузки с systemd
> А что, разработчики initrd и разработчики systemd - разве не одно и то же?"Разработчики initrd" -- в общем случае некорректный термин (для опровержения предлагаю попробовать его точно определить).
> А что, разработчики initrd и разработчики systemd - разве не одно и то же?Initrd был задолго до systemd. Такая вот неожиданность.
Дано: Gentoo & OpenRC
Делаем: rc-update del xdm default && rc-update add xdm boot
Итого: от граба до KDM проходит 2-3 секунды, systemd сосёт:)
> Дано: Gentoo & OpenRC
> Делаем: rc-update del xdm default && rc-update add xdm boot
> Итого: от граба до KDM проходит 2-3 секунды, systemd сoсётА если отключить OpenRC и оставить SysV init, будет грузиться еще быстрее :)
(OpenRC не умеет в параллельную загрузку, а SysV умеет)
> А если отключить OpenRC и оставить SysV init, будет грузиться еще быстрее :)
> (OpenRC не умеет в параллельную загрузку, а SysV умеет)Вообще-то, OpenRC - это просто избыточная прослойка над SysV init.
Когда-то, когда SysVinit не умел параллельной загрузки, поверх него придумали OpenRC, в котором планировалось реализовать эту функциональность.
Прошло несколько лет. SysVinit научился грузиться параллельно (чем активно пользуется дебиан), а OpenRC до сих пор зависает при включении rc_parallel=yes.
> Прошло несколько лет. SysVinit научился грузиться параллельно (чем активно пользуется
> дебиан), а OpenRC до сих пор зависает при включении rc_parallel=yes.А держится он в генте только потому, что так хочет один конкретный человек - Luca Barbato. Ничем не лучше поцтеринга, кстати.
Поэтому, когда тру-гентушники выступают против systemd - это смотрится довольно забавно :)
>> Прошло несколько лет. SysVinit научился грузиться параллельно (чем активно пользуется
>> дебиан), а OpenRC до сих пор зависает при включении rc_parallel=yes.
> А держится он в генте только потому, что так хочет один конкретный
> человек - Luca Barbato. Ничем не лучше поцтеринга, кстати.
> Поэтому, когда тру-гентушники выступают против systemd - это смотрится довольно забавно
> :)Gentoo вообще становится просто идиотским дистрибутивом. Все, что могу, перевожу потихоньку на дебиан. Hardened вот жалко, хорошее направление...
Но вообще когда на ноуте с e-350 aptitude быстрее работает и меньше грузит проц, чем emerge на 8-ми ядернике, это о чем-то говорит.
То они конфетки поцтеринг и ко дарят, то обновлении внезапно прилетает куча ненужной ерунды...
> Gentoo вообще становится просто идиотским дистрибутивом. Все, что могу, перевожу потихоньку
> на дебиан. Hardened вот жалко, хорошее направление...
> Но вообще когда на ноуте с e-350 aptitude быстрее работает и меньше
> грузит проц, чем emerge на 8-ми ядернике, это о чем-то говорит.Просто изначально Gentoo создавали технари, со своими хорошим технарскими идеями.
Но создать мало, надо еще поддерживать и допиливать. Но те технари уже ушли, остались одни филологи, которые занимаются косметической правкой второстепенных bash-скриптов, считая это крутым линукс-хацкерством.
> То они конфетки поцтеринг и ко дарятНу конфетки они дарили когда извинялись. После того, как они сначала громко кричали о "регрессиях" в udev, а потом их "исправленный" вариант оказался на порядок хуже исходного (фиговые кодеры из гуманитариев, да) - извинения были единственным способом сохранить лицо. За умение признать свои ошибки их нельзя не уважать.
> А держится он в генте только потому, что так хочет один конкретный
> человек - Luca Barbato. Ничем не лучше поцтеринга, кстати."Свое г-но не пахнет" (народная мудрость).
Зато openrc работает и на embedded и на отличных от linux OS, в отличии от systemd. Проблем с параллельным запуском я как то не видел последние пару лет в openrc.
> Зато openrc работает и на embeddedНа embedded работает все то же самое что и везде. И конкретно openrc никому там нафиг не упал.
>> Дано: Gentoo & OpenRC
>> Делаем: rc-update del xdm default && rc-update add xdm boot
>> Итого: от граба до KDM проходит 2-3 секунды, systemd сoсёт
> А если отключить OpenRC и оставить SysV init, будет грузиться еще быстрее
> :)
> (OpenRC не умеет в параллельную загрузку, а SysV умеет)SysV уже ничего не умеет, потому что эта ОС померла. Также нет стандартного и единого sysvinit-а - каждый дистрибутив пишет свой велосипед в sysv-стиле (или в bsd-стиле, но все равно СВОЙ).
В дебиане используется свой местечковый sysv-style init, поверх которого водружен insserv, помогающий разрешать зависимости. Но от этого параллельная загрузка в остальных дистрибутивах с их собственными sysv-style init системами не появляется.
Начал читать новость, тут же возникла мысль, что разработчики системд готовят себе почву, так сказать. И действительно> Стоит отметить, что в обсуждении один из разработчиков приводит довольно простой патч, который теоретически должен исправить эту проблему, путем перевода данной операции в ядре на асинхронный режим.
Начало systemd/linux (или GNU/systemd ?) положено.
> Начало systemd/linux (или GNU/systemd ?) положено.Еще в позапрошлом году в ядро приняли леннартовский патч, перекраивающий работу планировщика задач.
Кстати, нынче фичами этого патча пользуется не только systemd, но и upstart.
Показывать текст по видео - это пипец.
В духе поттеринговщины, чо.
Дожились, systemd тормозит без initrd.
Почему? Это ядро без initrd тормозит.
> Почему? Это ядро без initrd тормозит.Тормозит-то ядро, а виноват-то systemd. Он вообще во всем виноват. И воду в кране тоже он выпил.
> И воду в кране тоже он выпил.Хотя нет, воду выпил Поцтеринг.
> Хотя нет, воду выпил Поцтеринг.Нет, редхат. Без него линукс уже давно занимал бы 146% десктопов.
Ну а с ним убунта заняла эти 146%.. Конечно, если бы занял линукс, было бы лучше, но и так неплохо вышло.
Чего? Сколько там убунта заняла десктопов? Чьих десктопов? А линукс сколько всего занял десктопов? :))
Уверен, никто ни у кого ничего не занимал, всё осталось как и было ;)
> Чего? Сколько там убунта заняла десктопов?На данный момент - более 11 миллионов вроде как.
> Чьих десктопов?
Например, моих.
> Почему? Это ядро без initrd тормозит.Ну удивитесь наверное, но в ядре initramfs есть всегда, просто если на нем не находят /init или /bin/init или /sbin/init то происходит поиск корня механизмами ядра, что может занять время. Если initramfs есть то выполняется инит от туда
> Ну удивитесь наверное, но в ядре initramfs есть всегда,Возможен и вариант загрузки ядра совсем без начального рамдиска. Кстати сие отвечает на вопрос - почему на allwinner'ской вундервафле ядро несколько секунд тупит. Оно у меня как раз без рамдиска взлетает. Как ни странно, в ARMовой убунте...
У меня нету. За ненадобностью.
Наверное идея о том. что не следовало так анально заменять sysvinit на systemd, а для начала протестировать 2-3 года на добровольцах, отловив все глюки, выяснив узкие места, оптимизировать код и подготовить полностью готовую модель для каждого дистрибутива, внедряя, сохраняя старые системы инициализации, демонстрируя явные приимущества systemd перед прочими системами инициализации, спрашивая мнение сообщества "готовы ли вы отказаться от старой системы инициализации", и получив ответ "да готовы !!", ввиду того что systemd действительно рвет все прочие системы иницализации по всем фронтам - это идея быдло-дегенерата, больного шизофренией, болезнью паркинсона, а еще являющегося эталоном ретроградности.
ДА ?
> Наверное идея о том. что не следовало так анально заменять sysvinit на
> systemd, а для начала протестировать 2-3 года на добровольцах, отловив все
> глюки, выяснив узкие места, оптимизировать код и подготовить полностью готовую модель
> для каждого дистрибутива, внедряя, сохраняя старые системы инициализации, демонстрируя
> явные приимущества systemd перед прочими системами инициализации, спрашивая мнение сообщества
> "готовы ли вы отказаться от старой системы инициализации", и получив ответ
> "да готовы !!", ввиду того что systemd действительно рвет все прочие
> системы иницализации по всем фронтам - это идея быдло-дегенерата, больного шизофренией,
> болезнью паркинсона, а еще являющегося эталоном ретроградности.
> ДА ?Медленное и аккуратное внедрение бывает только в промышленных дистрах и всяких дебианах. Все остальные в большей или меньшей степени являются bleeding edge, и предпочитают решать проблемы по возможности быстрее.
Выбирайте тот дистрибутив, который действительно вам подходит, и таких проблем не будет.
> Все остальные в большей или меньшей степени являются bleeding edge, и
> предпочитают решать проблемы по возможности быстрее.Решать или создавать? Вчера одной юной бездари на пальцах уже пытался баланс пояснить.
> Наверное идея о том. что не следовало так анально заменять sysvinit на
> systemd, а для начала протестировать 2-3 года на добровольцах, отловив все
> глюки, выяснив узкие места, оптимизировать код и подготовить полностью готовую модель
> для каждого дистрибутива, внедряя, сохраняя старые системы инициализации, демонстрируя
> явные приимущества systemd перед прочими системами инициализации, спрашивая мнение сообщества
> "готовы ли вы отказаться от старой системы инициализации", и получив ответ
> "да готовы !!", ввиду того что systemd действительно рвет все прочие
> системы иницализации по всем фронтам - это идея быдло-дегенерата, больного шизофренией,
> болезнью паркинсона, а еще являющегося эталоном ретроградности.
> ДА ?Парочка вопросов на засыпку.
Дано:
все известные критические проблемы в багтрекере, которые могут блокировать выпуск, закрыты, производительность выше, чем была до этого и уже год-полтора добровольцы вовсю ставят этот софт и используют.Внимание, вопросы:
- Остались ли баги в софте?
- Через какой время ограниченного тестирования на добровольцах можно быть уверенным, что отловлены все баги и оптимизировано все, что можно?
- В каких нетестовых дистрибутивах сейчас есть по-умолчанию systemd?
> Внимание, вопросы:
> - Остались ли баги в софте?
> - Через какой время ограниченного тестирования на добровольцах можно быть уверенным,
> что отловлены все баги и оптимизировано все, что можно?
> - В каких нетестовых дистрибутивах сейчас есть по-умолчанию systemd?Это все вопросы к ментейнерам, баги конечно остались, с вероятностью от .. скажем 40% до 5%, в зависимости насколько усердно их отлавливали.
После того как, по мнению разработчиков, количество багов сведено к минимому - данный продукт нужно выкладывать в тестовые ветки репозитариев. После того как тестовый systemd начинает расползаться по компам добровольцев - начинают всплывать новые баги, так как повышается разнообразие конфигураций железа компьютеров у пользователя. Они натаклкиваются на баги, пишут багрепорты, баги фиксятся. После того, как кол-во сообщений о найденых багах сводится к минимому в абстрактную единицу времени - можно выкладывать systemd в стабильные ветки репозитариев, сохраняя при этом старую систему инициализации.
Тестовых и нетестовых дистрибутивов нет, или я не знаю такие - есть тестовые ветки репозитариев.
По умолчанию systemd в моем ArchLinux, к слову сказать из него ушло более одного ментейнера, по причине того что отказались от sysvinit в пользу systemd.
>[оверквотинг удален]
>> - В каких нетестовых дистрибутивах сейчас есть по-умолчанию systemd?
> Это все вопросы к ментейнерам, баги конечно остались, с вероятностью от ..
> скажем 40% до 5%, в зависимости насколько усердно их отлавливали.
> После того как, по мнению разработчиков, количество багов сведено к минимому -
> данный продукт нужно выкладывать в тестовые ветки репозитариев. После того как
> тестовый systemd начинает расползаться по компам добровольцев - начинают всплывать новые
> баги, так как повышается разнообразие конфигураций железа компьютеров у пользователя.
> Они натаклкиваются на баги, пишут багрепорты, баги фиксятся. После того, как
> кол-во сообщений о найденых багах сводится к минимому в абстрактную единицу
> времени - можно выкладывать systemd в стабильные ветки репозитариев,ты не поверишь, но именно так и делается. С открытыми критичными багами никто даже релиз не будет формировать. Потом новый софт уходит в тестовую ветку дистрибутива (в федоре - rawhide, в opensuse - factory), где проверяется добровольцами. И лишь затем, после того, как убедятся, что софт таки не содержит критичным багов, его либо кладут в текущий релиз (если это минорное обновление системного софта или мажорное - прикладного), либо откладывают до следующего релиза.
По крайней мере так делается в приличных десктопных дистрибутивах. Как в вашем арче заведено, я не знаю.> сохраняя при
> этом старую систему инициализации.старые init-скрипты в systemd до сих пор работают. во время переходного периода в приличных дистрибутивах, опять же, была возможность использовать старую init-систему. Но бесконечно поддерживать legacy на протяжении долгого времени ничто не будет, конечно. Один-два релиза и все.
А если в отдельных дистрибутивах майнтенеры мудаки и отдают пользователям софт без какого-либо QA, то это, извините, уже не Поттеринг виноват.
> С открытыми критичными багами никто даже релиз не будет формировать.Вот это новость, прям прошлым веком повеяло.
>> С открытыми критичными багами никто даже релиз не будет формировать.
> Вот это новость, прям прошлым веком повеяло.При чем тут прошлый век?
>>> С открытыми критичными багами никто даже релиз не будет формировать.
>> Вот это новость, прям прошлым веком повеяло.
> При чем тут прошлый век?При гонке за time to market, которая тогда ещё не допрогрессировала до того, что наблюдаем ныне.
Ну и трава была зеленей, понятное дело.
>>>> С открытыми критичными багами никто даже релиз не будет формировать.
>>> Вот это новость, прям прошлым веком повеяло.
>> При чем тут прошлый век?
> При гонке за time to market, которая тогда ещё не допрогрессировала до
> того, что наблюдаем ныне.При гонке за time to market увеличивают частоту релизов и используют различные agile-техники разработки в команде, но не начинают игнорировать баги.
> При гонке за time to market увеличивают частоту релизовДа.
> и используют различные agile-техники разработки в команде
Да.
> но не начинают игнорировать баги.
И их тоже, потому как запыхиваясь над релизами и закопавшись по уши в юзерсторисы -- как ни странно, всё равно всего не сделаешь.
Вы же понимаете, что требовать от двух женщин ребёнка через три месяца -- это гонка, а не оптимизация?..
>> При гонке за time to market увеличивают частоту релизов
> Да.
>> и используют различные agile-техники разработки в команде
> Да.
>> но не начинают игнорировать баги.
> И их тоже, потому как запыхиваясь над релизами и закопавшись по уши
> в юзерсторисы -- как ни странно, всё равно всего не сделаешь.
> Вы же понимаете, что требовать от двух женщин ребёнка через три месяца
> -- это гонка, а не оптимизация?..Вообще-то, большинство agile-подходов оринтированы именно на поддержание постоянной скорости работы в течение долгого времени и поставку качественного кода. Потому при нормально поставленной работе за релизами никто не бежит (да и зачем бежать если они и так часто выходят?) и баги также не игнорируются, ибо приоритетнее фич.
Разумеется, можно все испоганить и поставить с ног на голову, но ценность качественного кода и вред гонки со временем на истощение - это одни из основных идей.
>>> При гонке за time to market [...] используют различные agile-техники
>> это гонка, а не оптимизация
> Вообще-то, большинство agile-подходов оринтированыЯ о том, что если ttm ставить во главу угла, а разум свой отодвинуть и к чужому тоже не прислушиваться -- то получается именно гонка и дальше любые достоинства любых подходов идут лесом, потому что рано или поздно начнётся истерика вида "уже три месяца на исходе, где ребёнок?!".
Ну нет в разработке серебряной пули, с самыми лучшими инструментами и методологиями надо начинать с целей, людей и взаимопонимания.
>>>> При гонке за time to market [...] используют различные agile-техники
>>> это гонка, а не оптимизация
>> Вообще-то, большинство agile-подходов оринтированы
> Я о том, что если ttm ставить во главу угла, а разум
> свой отодвинуть и к чужому тоже не прислушиваться -- то получается
> именно гонка и дальше любые достоинства любых подходов идут лесом, потому
> что рано или поздно начнётся истерика вида "уже три месяца на
> исходе, где ребёнок?!".
> Ну нет в разработке серебряной пули, с самыми лучшими инструментами и методологиями
> надо начинать с целей, людей и взаимопонимания.Так при чему тут тогда прошлый век? Нормально поставленный процесс разработки и сейчас не редок. И в прошлом веке бардак тоже в некоторых компаниях был.
> Так при чему тут тогда прошлый век?При степени гоночности.
>> С открытыми критичными багами никто даже релиз не будет формировать.
> Вот это новость, прям прошлым веком повеяло.Чем именно? Windows 95? Играми Daggerfall, Reunion, X-com?
А какие у systemd недостатки что его все так не любят?
Только один - монструозный комбайн.
> Только один - монструозный комбайн.По сравнению с любым монолитным ядром меркнут все юзерспейсовские комбайны.
> Только один - монструозный комбайн.Это systemd-то комбайн? Вы еще coreutils не видели. Вот это - всем комбайнам комбайн! В один проект запихнуто куча программ совершенно разного назначения - кодирование base64, расчет хеш-сумм, изменение приоритета процесса, сортировка текста, смена владельца файла, вывод текущей даты и т.п.
Поскольку coreutils писаны а) давно и б) не Поттерингом, Это Совсем Другое Дело.
> Поскольку coreutils писаны а) давно ив) ранее это были fileutils, textutils и кто-то ещё третий.
> А какие у systemd недостатки что его все так не любят?В частности команда journalctrl -u postfix -n50 (тут кстати между -n и 50 не должно быть пробела, иначе команда вернет ошибку) дает задержку в 3-4 секунды. Последующие вызовы - более быстрые.
Гораздо больший по объему лог но не journalctl, а простой текстовый файл - выводит мнговенно с первого раза (cat /var/log/some.log | tail -n 50)
> cat /var/log/some.log | tail -n 50Не надо так делать. Даже теоретически tail -n 50 мог бы оптимизировать вывод.
>> cat /var/log/some.log | tail -n 50
> Не надо так делать. Даже теоретически tail -n 50 мог бы оптимизировать
> вывод.Да хоть
a=`cat /var/log/Xorg.0.log | tail -n 50`; if [ "$a" != "" ]; then echo `echo $a`; else if [ "$a" = "" ]; then echo "нечего выводить"; fi;fi
все равно будет быстрее
> a=`cat /var/log/Xorg.0.log | tail -n 50`; if [ "$a" != "" ];
> then echo `echo $a`Вот так виндузятники и палятся -- кому нужен хвост Xorg.0.log, слепленный в одну строку?
>> a=`cat /var/log/Xorg.0.log | tail -n 50`; if [ "$a" != "" ];
>> then echo `echo $a`
> Вот так виндузятники и палятся -- кому нужен хвост Xorg.0.log, слепленный в
> одну строку?То есть ты таки проверил :))) ?
> То есть ты таки проверил :))) ?То есть я-таки такое эээ... ладно, штатно вооружённым глазом вижу. ;)
а что, просто передать путь к файлу аргументом tail теперь не модно?
недостатки системд (повыбирал из разных веток linux.org.ru и ещё откуда-то):
-----Systemd — это, пожалуй, самая сложная init-система из существующих на данный момент.
Если подробнее, то:
Раньше в арче был BSD-Style Init. В нём последовательно запускались все демоны, указанные в rc.conf, а когда они все запустились, то стартовали и иксы.
Sysvinit остальных дистров отличается от арчевого bsdinit только тем, что вместо единого файла rc.conf используется каталог rc.d, который позволяет иметь разные списке. Но программа, которая их запускает, умеет запускать их параллельно, то есть иксы могут запуститься раньше, не дожидаясь остальных демонов. На многоядерных машинах это экономит время.
Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловн
ый запуск, монтирование и проверки файловых систем, запуск и остановки и т.д. Еесли вдруг в одном из узлов дерева что-то не так, то всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных в попытках найти и исправить причину...---
Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с if и for (а такое частенько бывает нужно), то в systemd такие вещи переписывают на Си (!) и компилируют, а сам файл прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service.
В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно искать среди исходников systemd (а также кучи других пакетов) нужный файл и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее любого навороченного баш-скрипта.----
к systemd претензия в том, что он — худшее, что могли выбрать арчеводы для init-системы. Да, то, что было в арче, ужасно. Но его можно было улучшить, хотя бы добавив обработку LSB-headers для параллельного запуска. Если не хотелось изобретать свой, можно было взять готовый openrc из gentoo, старенький initrg из suse или адаптировать под себя параллельную загрузку из дебиана. Но они выбрали худший возможный вариант — сломать всё и переписать заново используя самую сложную и кривую систему из всех, что можно было выбрать.
Если бы systemd работал .— все были бы рады. Любая программа идеальна, пока она делает то, что тебе надо. В теории. Но на практике таких программ не бывает. Всегда бывает нужно изменить что-то, оптимизировать под себя настройки, добавить собственный скрипт для автозапуска или поправить один из существующих. Наконец иногда вылазят баги после апдейта, которые надо быстро поправить и работать дальше. Арчеводы, как никто другой, должны об этом знать. Но поиск багов systemd — это ужас, как его настраивать знают не многие, а отлаживать его умеют единицы.
Простой пример: если заменить /tmp на симлинк в /home/tmp, то systemd сносит крышу и система не стартует. Как это починить? Как найти причину и исправить её?
Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus, (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера говорит о том, что арч больше не KISS. Какие ещё есть причины им пользоваться?----
>[оверквотинг удален]
> знают не многие, а отлаживать его умеют единицы.
> Простой пример: если заменить /tmp на симлинк в /home/tmp, то systemd сносит
> крышу и система не стартует. Как это починить? Как найти причину
> и исправить её?
> Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо
> init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus,
> (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервера
> говорит о том, что арч больше не KISS. Какие ещё есть
> причины им пользоваться?
> ----Ну вообще-то, если тебе так нужен if или ещё что-то, не обязательно писать сразу unit на Си. Ты можешь написать то, что тебе нужно на шелле, например, и запускать это юнитом. Просто разработчики systemd это делают на Си, видимо, скорости ради. Так что параноидальный бред про сложность и не гибкость в этом месте некорректен.
> Если бы systemd работал
Работает. Что я делаю не так?
А я согласен. Переписали бы на перле скрипты, да хоть на ноде.жс, хоть на пхп, но на си то нахрена, а ведь еще есть selinux и уефи наступает.. вместо тупого добавление пары строк в скрипт придется новый файл создавать, дублировать функционал старого, править права, контекстные права, и скрестив пальцы надеяться, что там не выползет еще какая хрень.У меня федора 2 месяца не простояла, после очередной обновы перестала грузится, ядро нормально, где-то на скриптах замирала и ждала хз чего, ни ошибок, ни ворнингов.
> А я согласен. Переписали бы на перле скрипты, да хоть на ноде.жс,
> хоть на пхп, но на си то нахрена, а ведь еще
> есть selinux и уефи наступает.. вместо тупого добавление пары строк в
> скрипт придется новый файл создаватьЕсли у вас возникает такая необходимость, значит, вы что-то делаете неправильно.
Программа должна настраиваться через конфигурацию, а не через код.> У меня федора 2 месяца не простояла, после очередной обновы перестала грузится,
> ядро нормально, где-то на скриптах замирала и ждала хз чего, ни
> ошибок, ни ворнингов.Нельзя просто взять и подвесить systemd. Любой юнит, даже если зависнет, все равно будет убит по таймауту (по умолчанию 5 минут). В отличие от SysV init, который виснет навсегда (приходилось сталкиваться, спасибо дебиану за это).
> Если у вас возникает такая необходимость, значит, вы что-то делаете неправильно.
> Программа должна настраиваться через конфигурацию, а не через код.Должна, но не обязана, прелесть линукса в гибкости, можно запустить демон, а можно два, вот на недели tftpd разворачивал, нету у нее конфига, как прикажете папку корня ftp менять.
> Нельзя просто взять и подвесить systemd. Любой юнит, даже если зависнет, все
> равно будет убит по таймауту (по умолчанию 5 минут). В отличие
> от SysV init, который виснет навсегда (приходилось сталкиваться, спасибо дебиану за
> это).SysV то еще убожество, но он прозрачен абсолютно, с момента запуска init можно контролировать его добавляя в скрипты выдачу отладочных мессаг в крайнем случае, можно передав параметр ядру сразу получить консоль и делать все в ручном режиме
> Должна, но не обязана, прелесть линукса в гибкости,Помнится, разработчики Windows в свое время реализовали довольно интересную задумку - унифицированную базу данных для хранения настроек программ (реестр). Но они не могли обязать разработчиков программ не устраивать там срача.
В результате разработчики программ с лозунгом "прелесть реестра в гибкости" мигом превратили его в помойку.Именно за это мы и любим текстовые конфиги - они совершенно негибкие, и их гораздо труднее загадить.
> вот на недели tftpd разворачивал, нету у нее конфига, как прикажете папку корня ftp менять.
В sysvinit - править инит-скрипт, который является кодом и поэтому будет затерт при следующем обновлении.
В systemd - поправить конфиг юнита, который является (внезапно) просто конфигом.> SysV то еще убожество, но он прозрачен абсолютно, с момента запуска init
> можно контролировать его добавляя в скрипты выдачу отладочных мессагА в systemd не надо ничего добавлять, достаточно в повысить loglevel до debug, и все его компоненты начнут писать в лог подробную отладочную информацию. Нормальный код имеет много преимуществ перед сметанными на живую нитку скриптами.
> обязать разработчиков программ не устраивать там срача.Плюс сами развели там срач. Плюс не дали утилит в системе для прозрачной работы с данными. Так что найти в реестре все ветки содержащие "вася" но не содержащие "петя" - это рокет сайнс. Так изначально вообще не предусмотрено. А с учетом объема ср@ча в реестр - там обычно почти все что угодно находится не менее 100500 раз.
> SysV то еще убожество, но он прозрачен абсолютно,Очень грустно, когда рассуждениями про "прозрачность" пытаются оправдать полное отсутствие вменяемой документации.
> Очень грустно, когда рассуждениями про "прозрачность" пытаются оправдать полное отсутствие вменяемой документации.Документация - не unix-way. Пусть всякие MSDN-ы документацию пишут, а мы и в код глянем.
> Документация - не unix-way.А как же маны???
> Очень грустно, когда рассуждениями про "прозрачность" пытаются оправдать полное отсутствие
> вменяемой документации.ешкин кот, да на кой черт документировать пять строк проверки наличия проги, конфига и его валидности?
> В результате разработчики программ с лозунгом "прелесть реестра в гибкости" мигом превратили его в помойку.
Винда сама себя в помойку превращает штатными средствами.
> Именно за это мы и любим текстовые конфиги - они совершенно негибкие, и их гораздо труднее загадить.
загадить можно все.
> А в systemd не надо ничего добавлять, достаточно в повысить loglevel до debug, и все его > компоненты начнут писать в лог подробную отладочную информацию. Нормальный код имеет много преимуществ перед сметанными на живую нитку скриптами.
Это если дело дошло до лога, это еще пойди тонну доков перечитай, по конфигурированию системд, и прочая прочая.
Да SysV убог, но зато прост и легко меняется полностью или частично, а главное работает, системд сам себе на уме, заменить его проблематично, любое действие требует курения манов.
Нет в нем и новшеств выгодно отличающих его, то есть меняем шило на мыло.Я писал уже как-то, что очень бы хотелось демона чьей задачей был бы контроль других демонов, только не так как это делают нагиосы, а полномаштабный, с интеграцией с системой, построением графиков использования ресурсов, возможно; с управляемой логикой в случае падения; может это не совсем то, но с интеграцией с dbus, с удалением функции запуска демонов из SysV - это был бы выход на новый уровень, а системд всего лишь велосипед.
> ешкин кот, да на кой черт документировать пять строк проверки наличия проги, конфига и его валидности?Я уже лет 20 не видет init-скрипты по пять строк.
С тем же успехом можно утверждать "зачем документировать apache, там же три строчки весь код".
> Винда сама себя в помойку превращает штатными средствами.
Как и SysV init.
> Это если дело дошло до лога, это еще пойди тонну доков перечитай,
> по конфигурированию системд, и прочая прочая.Да, одну man-страницу прочитать - неподъемный труд.
Уж лучше тыщу строчек индусокода, но зато на родном баше.> Да SysV убог, но зато прост и легко меняется полностью или частично,
> а главное работает, системд сам себе на уме, заменить его проблематично,
> любое действие требует курения манов.С компьютерами вообще сложно работать.
> Нет в нем и новшеств выгодно отличающих его, то есть меняем шило на мыло.
Да и у Linux никаких новшеств по сравнению с MS-DOS, ага. Такая же черная консоль :)
> Я писал уже как-то, что очень бы хотелось демона чьей задачей был
> бы контроль других демонов, только не так как это делают нагиосы,
> а полномаштабный, с интеграцией с системой, построением графиков использования ресурсов,
> возможно; с управляемой логикой в случае падения; может это не совсем
> то, но с интеграцией с dbus, с удалением функции запуска демонов
> из SysV - это был бы выход на новый уровеньТащемта, это systemd и есть. Разве что графики не строит (зато есть cgtop).
А графики и munin строить может.
> Я уже лет 20 не видет init-скрипты по пять строк.slackware, дома только он, на работе центос - корп стандарт и скрипты его не сложнее.
хотя иногда с ними тоже возникают траблы, напримет неспособность проверить корневую фс, так как там прописано проверять /, и вдруг ни с того ни с сего он обнаруживает что это папка соответсвенно скрипт вылетает в ошибку и система не грузится, на SysV встречал эту проблему часто и на рэдхате и на альте, и на компах, и на серверах, и встраиваемых системах, дейсвительно хрен поймешь, что в этих скриптах не отрабатывает, но на худой конец можно снести весь огород и сделать тупое fsck /dev/sdx> С тем же успехом можно утверждать "зачем документировать apache, там же три
> строчки весь код".если бы это было действительно так.
> Как и SysV init.
ну на убунте мб, в центосе все кашерно.
> Да, одну man-страницу прочитать - неподъемный труд.
> Уж лучше тыщу строчек индусокода, но зато на родном баше.а она одна? речь собственно и идет про замену кучи скриптов на кучу бинарников
> С компьютерами вообще сложно работать.
в компьютерах нолики да единички, работать сложно с идиотами, поттеринг может и не идиот, но выскочка и порядочный засранец.
> Да и у Linux никаких новшеств по сравнению с MS-DOS, ага. Такая
> же черная консоль :)Пфф
> Тащемта, это systemd и есть. Разве что графики не строит (зато есть
> cgtop).
> А графики и munin строить может.может и прикрутили что уже, не в курсе, только вот udev делает свою работу и никто его его не хаит, а системд и диски монтирует и за процессами следит, так пусть он тогда дбас зпменит и удев, и глибц, и может поттеринг и ядро свое запилит?
>> Я уже лет 20 не видет init-скрипты по пять строк.
> slackware, дома только он, на работе центос - корп стандарт и скрипты его не сложнее.если бы это было действительно так ©
> ну на убунте мб, в центосе все кашерно.
Вот не надо ля-ля. Я с 4-5 центосом работал довольно плотно. Переход 6-го на upstart снес порядочную часть sysvinit-го геморроя. И уже очень хочется, чтобы поскорее вышел 7-й с systemd, чтобы забыть еще кучу проблем.
> а она одна? речь собственно и идет про замену кучи скриптов на кучу бинарников
Для 1 юнита + 1 вызываемого из него бинарника - одна. Хотя бывает, что несколько юнитов и бинарников делают разные части одной работы (например, readahead-collect, readahead-replay) - тогда и man-страница у них одна.
> Пфф
Ну теперь вы поняли, как практикующие админы относятся к заявлениям "у systemd никаких полезных новшеств, один гемор" :)
> может и прикрутили что уже, не в курсе, только вот udev делает
> свою работу и никто его его не хаитГентушники хаяли. Правда, потом извинялись и дарили конфеты.
> Ну теперь вы поняли, как практикующие админы относятся к заявлениям "у systemd
> никаких полезных новшеств, один гемор" :)Как практикующий админ, у systemd никаких полезных новшеств, один гемор.
> Гентушники хаяли. Правда, потом извинялись и дарили конфеты.Хаяли не сам удев а что с ним пытался сделать поттеринг, после того как вставил в systemd. Удев попросту больше нельзя собрать не собрав остальных компонентов systemd, потеряна совсместимость удава со старыми ядрами (да да ваши любимые 2.6.32 перестают работать с новым удавом) и тп.
> 6-го на upstart снес порядочную часть sysvinit-го геморроя.Я упорото не могу понять, почему вы считаете что sisvinit - геммор, а systemd манна небесная.
Я вот считаю что наоборот - systemd, это геммор, а sysvinit - это то, "каким линукс должен быть". Во всяком случае тот. что был в Арче.
Вы никогда не сталикавались с тем, что с systemd почему-то драйвер на сетевую карту не загружался на 100ую загрузку, хотя 99 раз перед этим загружался ?
Мне кажется это происходит потому что он не успевает загрузиться, потому что "агрессивная параллелизация".
Или имена интерфйесов сетвеых не менялись на "не правильные" ?
Жесткие диски sda sdb именами не менялись после перезагрузки ?Когда вы перейдете на systemd, это вас все ждет, не обязательно сразу, но обязательно ждет, если вы конечно не эксперт-телепат, который может видеть будущее.
> хотя иногда с ними тоже возникают траблы, напримет неспособность проверить корневую фс,
> так как там прописано проверять /, и вдруг ни с того ни с сего он обнаруживает что это
> папка соответсвенно скрипт вылетает в ошибку и система не грузится, на SysV встречал
> эту проблему часто и на рэдхате и на альтеПокурочили ФС или fstab с UUID.
угумс, вдруг не с того не с сего на встраиваемой системе что-то покурочилось, да так смачно, что извлечение винта и проверка его на другой системе ни ошибок не выявила, ни загружаемость системы не восстановила.
маловероятно, но не невозможно.
> Я уже лет 20 не видет init-скрипты по пять строк.http://svnweb.freebsd.org/base/release/9.0.0/etc/rc.d/rwho?v...
А если стандартные вычесть, так даже и меньше пяти останется.
>Я писал уже как-то, что очень бы хотелось демона чьей задачей был бы контроль других демонов...Но не придумал, чем отвлечь санитаров.
> Я писал уже как-то, что очень бы хотелось демона чьей задачей был
> бы контроль других демонов, только не так как это делают нагиосы,
> а полномаштабный, с интеграцией с системой, построением графиков использования
> ресурсов, возможно; с управляемой логикой в случае паденияПосмотрите monit+collectd? Каждый прекрасно решает свои задачи.
> Каждый прекрасно решает свои задачиНе надо сказок.
Что monit cделает если основной процесс некоего демона нарожал потомков, а потом аварийно завершился ?
Как сказать мониту "останови демона X и не перезапускай его пока я не прикажу" ?
Как _гарантированно_ избежать состязаний при загрузке ?
> Не надо сказок.Правильно, а вот почти десяток лет боевой эксплуатации кое-что говорит.
> Что monit cделает если основной процесс некоего демона нарожал потомков,
> а потом аварийно завершился ?Что скажут, то и делает -- например, дёргает скрипт рестарта (который может уже более вдумчиво разбираться, что там такое -- хотя криво падающий софт как-то даже страшновато представить в своей зоне ответственности) и пишет руту.
> Как сказать мониту "останови демона X и не перезапускай его пока я не прикажу" ?
monit stop X
> Как _гарантированно_ избежать состязаний при загрузке ?
Оформив страховой полис, что Вы как маленький?
>> Не надо сказок.
> Правильно, а вот почти десяток лет боевой эксплуатации кое-что говорит.Опыт говорит что нормальных решений сейчас не существует, есть наборы костылей разного радиуса кривости.
>> Что monit cделает если основной процесс некоего демона нарожал потомков,
>> а потом аварийно завершился ?
> Что скажут, то и делает -- например, дёргает скрипт рестарта (который может
> уже более вдумчиво разбираться, что там такоеДа щас. 99.(9)% скриптов ни в чем разбираться не будут и тупо оставят порожденные процессы болтаться в системе дальше.
> -- хотя криво падающий
> софт как-то даже страшновато представить в своей зоне ответственности) и пишет руту.За "десяток лет боевой эксплуатации" никогда не видели падения демона? Ну, ну.
>> Как сказать мониту "останови демона X и не перезапускай его пока я не прикажу" ?
> monit stop XЭто радует.
>> Как _гарантированно_ избежать состязаний при загрузке ?
> Оформив страховой полис, что Вы как маленький?То есть ответа не будет ?
>>> Что monit cделает если основной процесс некоего демона нарожал потомков,
>>> а потом аварийно завершился ?
>> Что скажут, то и делает -- например, дёргает скрипт рестарта (который может
>> уже более вдумчиво разбираться, что там такое
> Да щас. 99.(9)% скриптов ни в чем разбираться не будут и тупо
> оставят порожденные процессы болтаться в системе дальше.Ещё раз:
- если это неисправимо в самой софтине (например, бинарь) -- остаётся только подпирать так или иначе, причём будет это рестарт сервера/виртуалки/контейнера или прибитие всего живого в неймспейсе -- разницы катастрофической нет, т.к. у _этой_ медали обратная сторона _есть_ и известна (выплёскивание с водой младенца по шаблонному невниманию);
- если это исправимо в софтине, исправлять поведение следует именно там -- возможно, временно используя предыдущий пункт в качестве объезда.>> -- хотя криво падающий
>> софт как-то даже страшновато представить в своей зоне ответственности) и пишет руту.
> За "десяток лет боевой эксплуатации" никогда не видели падения демона? Ну, ну.Если бы не видел, monit бы не упоминал (только не десяток, а полтора уже скоро).
Настолько криво падающих и впрямь сходу не припомню.
>>> Как _гарантированно_ избежать состязаний при загрузке ?
>> Оформив страховой полис, что Вы как маленький?
> То есть ответа не будет ?Каков вопрос, таков ответ. Про гонки под конкретно systemd писал недавно и достали они достаточно крепко, чтобы лишний раз даже вспоминать не хотелось.
> Посмотрите monit+collectd? Каждый прекрасно решает свои задачи.Ага, и будет у нас лоскутное одеяло запускалок. Половина программ запускается там. Половина - сям, а некоторое вообще вон оттуда взлетает. Вот смотришь на конкретную программу - и попробуй угадать: откуда ее такую хорошую запустили. Очень удобно - шариться в три-четыре закоулка системы вместо одного. Это на сервере. На десктопе все еще веселее...
> Посмотрите monit+collectd? Каждый прекрасно решает свои задачи.Спасибо, посмотрел, не то это
collectd - по мотивам cacti, видимо, имел удовольствие ковырять, обрезать ошибки до 20 символов полученные от дочерних процессов это сильно.
monit - аля nagios, какая-то студенческая свистоперделка, брать id процесса из pid-файла, а если id уже получен другим процессом, проверять контрольную сумму /proc/<pid>/exe?
Комплексное решение хочется, чтобы pid получать от fork-exec, отслеживать создание потомков, данные читать в виде как есть, а не процентами от чего-то там, и не генерить их каждые 10 сек, а предоставлять по требованию, динамически конфигурировать список наблюдаемых процессов, и лучшим вариантом тут будет виртуальная фс, кстате в качестве плюшки можно писать на эту фс логи, а денон будет их парсить и по регекспам генерировать события, не говоря уже о решении проблемы с ротацией логов.
есть подозрение (без сарказма), что способы получить реализацию этой хотелки — как обычно. или пишем сами, или платим тем, кто нам напишет.
> есть подозрение (без сарказма), что способы получить реализацию этой хотелки — как
> обычно. или пишем сами, или платим тем, кто нам напишет.)), ну да, только за мои деньги я попрошу не иначе как шедевр, и ни малейшего представления нет кто бы мог это сделать, а самому... так проще скриптами)), с 9 до 9 на работе и это блин отпуск).
> )), ну да, только за мои деньги я попрошу не иначе как
> шедеврну… составляй договоры, контролируй работу и всё такое. ну, и получишь на выходе как обычно, конечно.
> и ни малейшего представления нет кто бы мог это сделать
всё зависит от суммы, которую ты готов потратить, и от сроков, которые ты готов поставить. как-то так.
> а самому… так проще скриптами
вот все вы так. сначала Такое-То Описание, а потом в кусты…
> ну… составляй договоры, контролируй работу и всё такое. ну, и получишь на
> выходе как обычно, конечно.
> всё зависит от суммы, которую ты готов потратить, и от сроков, которые
> ты готов поставить. как-то так.Не согласен, это удача - найти человека способного выполнить то, что ты хочешь и так как ты хочешь, в большенстве случаев, хочешь сделать хорошо - сделай сам.
>> а самому… так проще скриптами
> вот все вы так. сначала Такое-То Описание, а потом в кусты…ну не совсем, мои скрипты меня вполне устраивают, они как раз умеют запускать процесс гарантированно получать его pid и отличать его в последствии от другого получившего тот же id, конечно отслеживать потомков и прочая прочая мечта, но писались они под более широкий спектр задач с прицелом на маленький-эффективный-универсальный
> Спасибо, посмотрелНе, не посмотрели, но дело хозяйское.
> Не, не посмотрели, но дело хозяйское.Скажем так, увидел, что оно из себя представляет, или чего не представляет, объем скриптов, которые надо написать или поправить, для вменяемой объвязки сравним с объемом проекта, который бы делал то, что нужно, если писать самому, и в добавок синхронизировать это на разных машинах, администрировать разные части в разных местах, и в результате - весь выигрышь уходит в ноль, если не падает ниже.
> Нельзя просто взять и подвесить systemd.Что, и сегфолтнуть тоже нельзя? Меня посодють? :]
>> Нельзя просто взять и подвесить systemd.
> Что, и сегфолтнуть тоже нельзя? Меня посодють? :]Сегфлотнуть можно все, даже баш.
> Сегфлотнуть можно все, даже баш.Вам удавалось сегфолтнуть bash? Мне пока нет, а systemd -- да.
>> Сегфлотнуть можно все, даже баш.
> Вам удавалось сегфолтнуть bash? Мне пока нет, а systemd -- да.
$ alias r="fc -e -"
$ r r
<здесь будет ругань>
$ r r
r r
r r
<... много-много раз...>
KABOOM!Работает (практически?) во всех bourne-шеллах. :)
эм...
$ bash
$ fc
bash: vi: command not foundwtf?!
> эм...
> $ bash
> $ fc
> bash: vi: command not found
> wtf?!О, глядишь, так и получится поприучать линуксоидов читать man'ы... А там, глядишь, они их и писать снова нормальные начнут. :)
$ man fc
No manual entry for fc
> $ man fc
> No manual entry for fcТеплее... Даю подсказку: чем отличаются "ls" и "/bin/ls"?
да не надо, туплю я просто.
чёрт. что-то я спросонок торможу, фигню написал.
> Работает (практически?) во всех bourne-шеллах. :)
$ r r
-bash: fc: не нашел такую команду
Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %)
>> Работает (практически?) во всех bourne-шеллах. :)
>$ r r
> -bash: fc: не нашел такую команду
> Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %)Я ж специально написал, что срабатывает со второго ввода...
>>> Работает (практически?) во всех bourne-шеллах. :)
>>$ r r
>> -bash: fc: не нашел такую команду
>> Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %)
> Я ж специально написал, что срабатывает со второго ввода...Действительно; bash завершился с errorlevel 1, но не по SIGSEGV.
> Действительно; bash завершился с errorlevel 1, но не по SIGSEGV.у меня с размаху сегфолтнулся. 4.2.37(2)
а вот zsh отказался сегфолтится: «fc: event not found: r», сколько раз ему «r r» ни делай.
>>>> Работает (практически?) во всех bourne-шеллах. :)
>>>$ r r
>>> -bash: fc: не нашел такую команду
>>> Ой, вот ведь незадача -- фиксить у тестового пользователя нечего %)
>> Я ж специально написал, что срабатывает со второго ввода...
> Действительно; bash завершился с errorlevel 1, но не по SIGSEGV.Разные шеллы в разных ОС выдают разное, в зависимости от своего устройства, направления роста стека и так далее. У меня bash - сейчас проверил - вообще вылетает с "Illegal instruction (core dumped)". ksh - до каких-то там фиксов - вылетал, кажись, как раз с SIGSEGV.
P.S.: Я - спать.
>> Сегфлотнуть можно все, даже баш.
> Вам удавалось сегфолтнуть bash? Мне пока нет, а systemd -- да.Мне как-то удавалось двухстрочным скриптом стабильно сегфолтить баш.
> Мне как-то удавалось двухстрочным скриптом стабильно сегфолтить баш.Было бы интересно на него посмотреть, если вдруг ещё найдётся; в любом разе спасибо.
>> Мне как-то удавалось двухстрочным скриптом стабильно сегфолтить баш.
> Было бы интересно на него посмотреть, если вдруг ещё найдётся; в любом
> разе спасибо.Дело было больше полугода назад и, разумеется, проблемная часть была сразу же переписана.
Помню только, что дело было, вроде, при использовании конструкции вида
${parameter##word} или подобного рода.
> > Если бы systemd работал
>
> Работает. Что я делаю не так?Видимо, не программируете и не администрируете.
>> > Если бы systemd работал
>>
>> Работает. Что я делаю не так?
> Видимо, не программируете и не администрируете.Я так люблю такие пустословные предположения!
И с нетерпением жду описание проблем, возникших в процессе эксплуатации systemd. А также, в идеале, ссылку на заведённый баг в трекере.
Что касается моей скромной персоны. На продакшн-серверах systemd нет, ибо убунта, и никто не будет менять ОС ради смены системы инициализации, это не самоцель. По-большому счёту, там мне пофигу, что за инит используется. Работает, не кукарекает, ну и ладно.
Но от использования systemd бы не отказался, многие вещи там сделаны удобно (или просто сделаны, в отличие от init).Касательно программирования. Да, ничего кроме автоматизирующих рутину скриптов я не пишу.
Но на десктопе я использую systemd для загрузки программ в пользовательской сессии (i3wm, pulseaudio, urxvtd). И юнит-файлы к ним я писал сам. И это элементарно. И удобно.Вообще, сама идея выделить в отдельную сущность запускалку абстрактных приложений и определять путь до бинарника + аргументы/(pre|post)-start хуки и тд в конфигурацию гораздо логичне, чем писать на каждый чих свою запускалку, тому же на шелле, не так ли? Это как бы абстракция, причём, вполне закономерная.
> Вообще, сама идея выделить в отдельную сущность запускалку абстрактных приложенийОбщую часть выделить -- да, мысль здравая. Беда в другом -- где-то передел и попытки вылепить на Це то, что лучше и прозрачнее делается на шелле, а где-то недодел и игнорирование тех самых багрепортов, которых зачем-то хотите, как если бы имеющихся было мало (неужели уже свою часть исправили?).
> Но на десктопе я использую systemd для загрузки программ в пользовательской сессии
> (i3wm, pulseaudio, urxvtd). И юнит-файлы к ним я писал сам. И это элементарно. И удобно.И чем же это элементарнее и удобнее ~/.xsession.d/?
>> Вообще, сама идея выделить в отдельную сущность запускалку абстрактных приложений
> Общую часть выделить -- да, мысль здравая. Беда в другом --
> где-то передел и попытки вылепить на Це то, что лучше и
> прозрачнее делается на шелле, а где-то недодел и игнорирование тех самых
> багрепортов, которых зачем-то хотите, как если бы имеющихся было мало (неужели
> уже свою часть исправили?).Я думаю, что тут один язык (Си) выбран исключительно унификации ради. Про игнорирование багрепортов не слышал, если просветите, буду признателен.
>> Но на десктопе я использую systemd для загрузки программ в пользовательской сессии
>> (i3wm, pulseaudio, urxvtd). И юнит-файлы к ним я писал сам. И это элементарно. И удобно.
> И чем же это элементарнее и удобнее ~/.xsession.d/?А я не говорил, что это чем-то элементарнее или удобнее, чем .xsession.d. Но это элементарно и удобно в целом. Как приятные бонусы - более быстрый старт (хотя в этом месте мне фиолетово) и возможность использовать бОльшую часть systemd-* утилит для разбора полётов, мониторинга и диагностики. А-ля systemctl --user --failed и systemctl --user status.
Но в целом согласен, это не киллер-фичи. Но я и не претендовал, я лишь указывал на то, что юнит-файлы systemd - это не бинарные конфиги и не какое-то непонятное зло, а простые текстовые конфиги. А то выше товарищ некий рассказывал ужасы какие-то.
> Я думаю, что тут один язык (Си) выбран исключительно унификации ради.Как уже не раз приводилось в примерах -- унификация бывает как полезная (взаимозаменяемость деталей), так и безмозглая (ездить на самосвале за батоном в соседний магазин). В частности, когда люди с явно недостаточным опытом системного администрирования берутся слепить всё "как лучше" -- выходит нередко уродство, непригодное к собственно администраторскому применению.
Опять вспоминается http://egorfine.com/ru/articles/worse-than-failure/ и упоминаемый там The Tool, кстати.
> Про игнорирование багрепортов не слышал, если просветите, буду признателен.
Да гляньте хотя бы шляпную багзилу по systemd в федоре, регулярно натыкаюсь. Повесят, повисит, поговорят, висит дальше.
А если бы внедрение не форсировали, то и фидбэк было бы больше возможности разгребать рабочим порядком.
>> И чем же это элементарнее и удобнее ~/.xsession.d/?
> А я не говорил, что это чем-то элементарнее или удобнее, чем .xsession.d.А-аа. Тут просто raorn@ то же самое несколько дней назад упоминал, я и заинтересовался -- правда, ответа по существу и там не получил.
В любом разе спасибо.
> И с нетерпением жду описание проблем, возникших в процессе эксплуатации systemd.
> А также, в идеале, ссылку на заведённый баг в трекере.Да, вот очередное и опять вследствие безмозглой асинхронности -- можете приступать к исправлению (если дело будет только за переводом на английский и его ещё нет, берусь сделать): https://bugzilla.altlinux.org/28805
>> И с нетерпением жду описание проблем, возникших в процессе эксплуатации systemd.
>> А также, в идеале, ссылку на заведённый баг в трекере.
> Да, вот очередное и опять вследствие безмозглой асинхронности -- можете приступать к
> исправлению (если дело будет только за переводом на английский и его
> ещё нет, берусь сделать): https://bugzilla.altlinux.org/28805Что-то этакое у меня было, когда устанавливал арч на новый ноут. Всё решилось прописыванием
KEYMAP=ru
FONT=cyr-sun16
в /etc/vconsole.conf. После этого русские шрифты в текстовой консоли стали нормальные. Сейчас специально переключился в консоль - проблема не проявляется, несмотря на периодические обновления systemd. Не знаю, та же у вас проблема или нет по своей сути.И справедливости ради. Я не пытался доказать, что багов в systemd нет. Они везде есть. Речь о том, что писать комментарии, вроде того, на который я ответил первоначально, без каких либо обоснований своих слов глупо.
это проблема не в системд, а в плимуте. Исправлено в плимуте.
Подобных багов не один и не два. Вот еще (под конец вид проблемы отличается):
https://bugzilla.redhat.com/show_bug.cgi?id=892340
> это проблема не в системд, а в плимуте.Та, на которую сослался -- вылазила и без plymouth. Майнтейнер опять починил, дифф не смотрел ещё...
Запили unit и запили init скрипт, нафига мне systemd тогда?
> Запили unit и запили init скрипт, нафига мне systemd тогда?Если это исключение -- то ещё может быть смысл. Если же перекрывание штатных юнитов и лепка обёрток к инитскриптам оказывается частым явлением, вот тогда именно такой вопрос и встаёт.
> Еесли вдруг в одном из узлов дерева что-то не так, то
> всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных
> в попытках найти и исправить причину...Как только люди не страдают, лишь бы логи не читать. А ведь там прямо написано, что, когда и почему не запустилось.
> Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с
> if и for (а такое частенько бывает нужно), то в systemd
> такие вещи переписывают на Си (!) и компилируют, а сам файл
> прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service.В принципе, то же самое можно сделать хоть на баше, но будет мееедленно.
> В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно
> искать среди исходников systemd (а также кучи других пакетов) нужный файл
> и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее
> любого навороченного баш-скрипта.Квадратно-гнездовое мышление времен SysV, когда была традиция не документировать процесс загрузки, так что узнать назначение скрипта можно было только чтением его кода.
А в эпоху systemd, чтобы понять назначение любого стандартного юнита, достаточно прочитать его manpage.
> ----
> к systemd претензия в том, что он — худшее, что могли выбрать арчеводы для init-системы.
> ...Ну и дальше поток сознания ЛОР-клоуна AX (одноклассник Зенитура). Никаких аргументов, одни эмоции. Даже комментировать не стоит.
> Раньше считалось, что арч хорош потому, что он KISS. Но использование вместо
> init-а велосипедокомбайна из (неполный список) init-демона, syslog-а, udev, cron, dbus,
> (x)inetd, readahead, ulatencyd, kdm/gdm/xdm, consolekit, sethostname, mount и http-сервераНу дык все правильно. Вместо кучи велосипедов, каждый из которых нужно изучать отдельно - одно нормальное решение, которое можно изучить один раз. Простота - залог здоровья!
нормальный скрипт в данном контексте не нуждается в документации, на то он и скрипт - 4 функции start/stop/restart/status, если чтение его вызывает проблемы, лучше не трогать, целее система будет, его можно воспринимать как конфиг со стандартным синтаксисом, а вы пытаетесь заменить это программой со своим конфигом и мануалом, зачем только не понятно.
> нормальный скрипт в данном контексте не нуждается в документации,Весьма спорное утверждение.
> на то он и скрипт - 4 функции start/stop/restart/status, если чтение его вызывает проблемы,
> лучше не трогать, целее система будет, его можно воспринимать как конфиг
> со стандартным синтаксисом, а вы пытаетесь заменить это программой со своим
> конфигом и мануалом, зачем только не понятно.Затем, что язык программирования - это нифига не конфиг, очевидно же.
Не надо смешивать настройки и код.
Между прочим, это ключевые принципы классического unix-way:
- никакой документации (кому надо - путь читает сорцы)
- конфигурация и код едины (надо настроить - правь код)Во всяком случае, именно такое впечатление складывается, если верить сторонникам sysvinit.
>Между прочим, это ключевые принципы классического unix-way:
>- никакой документации (кому надо - путь читает сорцы)Короткий и локальный код должен быть самодокументированным, вынос документации за пределы кода обычно не нужен и вреден. Например, вряд ли кому-то потребуется читать документацию к конкретным инитскриптам вне контекста чтения или правки самих скриптов (разве что общий обзор специфичных для дистрибутива решений).
>- конфигурация и код едины (надо настроить - правь код)
Конфигурация в общем случае пишется на языке сценирования конфигурируемой программы. (В частности, чтобы не плодить сущностей и не задавать два формата: один формат (язык) для сценирования, второй --- для конфигурирования).
Вполне естественно, что конфигурирование самой ОС (в частности, инитскрипты) пишется на стандартном языке сценирования ОС (sh), а не в выдуманном кем-то формате нестандартной программы.
>Во всяком случае, именно такое впечатление складывается, если верить сторонникам sysvinit.
Это действительно часть Unix Way. Третье поколение программистов и администраторов свидетельствует.
> - никакой документацииА маны - это, типа, не юникс вэй? Как интересно.
> (кому надо - путь читает сорцы)
Вот только юникс был проприетарной системой. И сорцев соответствнено не было.
> - конфигурация и код едины (надо настроить - правь код)
См. выше.
Это когда и где в Unix не было исходников?
>А маны - это, типа, не юникс вэй? Как интересно.Попробуйте (в нормально, не отпоттеросяненной ОС)
$man initscript
и приколитесь.
Чушь какая. Разве что в головах фанатов, извративших оригинал.Вот тут http://old.intuit.ru/department/os/osunix/ в первых трех главах нормально изложено.
> Затем, что язык программирования - это нифига не конфиг, очевидно же.
> Не надо смешивать настройки и код./etc/rc.d/
знаете для чего нужна папка etc?
Программа для запуска программы - дисонанса не улавливаете?
> /etc/rc.d/
> знаете для чего нужна папка etc?В SysV init - для хранения программ.
> Программа для запуска программы - дисонанса не улавливаете?
Ну дык SysVinit-way во все поля.
>> /etc/rc.d/
>> знаете для чего нужна папка etc?
> В SysV init - для хранения программ.Когда программы лежат в /etc и запускают другие программы - это и есть unix-way! Тупым systemd-фанатикам не понять :)
> Когда программы лежат в /etc и запускают другие программы - это и
> есть unix-way! Тупым systemd-фанатикам не понять :)А еще всякие *bin-ы - для лохов! Настоящие юниксоиды там конфиги хранят. Но systemd-фанатикам, опять же, не понять.
> Когда программы лежат в /etcа они там не лежат. там лежат конфиги и стартовые скрипты. все правятся текстовыми редакторами. не улавливаю диссонанса.
> знаете для чего нужна папка etc?
> Программа для запуска программы - дисонанса не улавливаете?Вы недалеки от просветления. Это и есть Unix Way: запускать программы по возможности программами.
Вручную пусть всё запускают те, кто каталоги "папками" называет.
> Затем, что язык программирования — это нифига не конфиг, очевидно же.
> Не надо смешивать настройки и код.видимо, именно поэтому у системд есть таки условия в «конфигах». корявые, неудобные, но есть. внизапна! это уже язык программирования. хоть и не тюринг-полный. не кидайся камнями из стеклянного дома.
Кстати, да, на рефале написать систему инициализации было бы круто.
> Кстати, да, на рефале написать систему инициализации было бы круто.Так пишите, кто вам не дает?
> Квадратно-гнездовое мышление времен SysV, когда была традиция не документировать процесс
> загрузки, так что узнать назначение скрипта можно было только чтением его
> кода.
> А в эпоху systemd, чтобы понять назначение любого стандартного юнита, достаточно прочитать
> его manpage.А вы manpag'у на все 100% доверяете :) ? может в нем какая-то неточность есть, или смысл выражений можно как-то двояко трактовать ? Или ментейнеры не досмотрели и не обновили manpage ?
Я вот считаю, что действительно понять как работает скрипт - можно увидев его код, просто пробежав глазами.
> Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает
> дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих
> unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловный запуск, монтирование и проверки файловых систем, запуск и остановки и т.д.
> Еесли вдруг в одном из узлов дерева что-то не так, то
> всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных
> в попытках найти и исправить причину...IMO построить дерево запуска можно (и нужно) статически, что впрочем вполне успешно делается таким простым средством, как insserv.
> Sysvinit остальных дистров отличаетсяне отличаЕтся, а отличаЮтся.
> программа, которая их запускает, умеет запускать их параллельно
Сам инит параллельно ничего без нашлепки сверху под названием insserv (которая есть только в дебиане и Ко) запускать не умеет.
> могут запуститься раньше, не дожидаясь остальных демонов. На многоядерных машинах это
> экономит время.
> Systemd пошел дальше. Вместо простого списка сервисов, которое надо запустить, он описывает
> дерево запуска. Каждый его unit-файл описывает узел этого дерева. И этих
> unit-файлов сотни. Через unit-ы в нём описано всё, условный и безусловн
> ый запуск, монтирование и проверки файловых систем, запуск и остановки и т.д.А как ты хотел без построения дерева зависимостей эти самые зависимости выяснить?
> Еесли вдруг в одном из узлов дерева что-то не так, то
> всё поддерево перестает запускаться. Это вызывает море удовольствия в часах проведенных
> в попытках найти и исправить причину...Я, наверное, не буду оригинальна, однако замечу, что в логах есть эхм... скажем так, сортировка по времени. Очень сильно помогает узнавать с чего начались проблемы.
> Поскольку юнит — это не скрипт и туда нельзя запихнуть конструкции с
> if и for (а такое частенько бывает нужно), то в systemd
> такие вещи переписывают на Си (!) и компилируют, а сам файл
> прописывают только запуск /usr/lib/systemd/systemd-<name>. Типичный пример: systemd-fsck-root.service.Если тебе так хочется свой скрипт проверки ФС, то напиши его и вызывай юнитами, кто тебе запрещает? Тебе еще и меньше кода писать придется из-за отсутствия необходимости соблюдать LSB-соглашения.
> В результате, чтобы просто узнать, что именно делает этот долбаный юнит, нужно
> искать среди исходников systemd (а также кучи других пакетов) нужный файл
> и разбираться в каше сишного кода. Которая, к слову, выглядит пострашнее
> любого навороченного баш-скрипта.К слову, у Поттеринга и Ко код написан хорошо и понятно.
> > программа, которая их запускает, умеет запускать их параллельно
>
> Сам инит параллельно ничего без нашлепки сверху под названием insserv (которая есть
> только в дебиане и Ко) запускать не умеет.А ничего, что insserv выстраивает скрипты в /etc/rc?.d/ _не во время загрузки системы_,
а в процессе загрузки совсем не участвует?
> А как ты хотел без построения дерева зависимостей эти самые зависимости выяснить?hint: эту операцию не так много смысла выносить в рантайм, т.к. относительно одного и того же набора это дерево должно быть инвариантно; при этом помимо потенциальной задумчивости солвера и необходимости как-то неинтерактивно разрывать возможные циклы получается возможность сильно упростить критический для запуска системы код. Соответственно обновление кэша можно выполнять утилитой, которую дёргать в т.ч. из пакетных менеджеров и у которой будет шанс внятно вывалиться при проблемах.
> Я, наверное, не буду оригинальна, однако замечу, что в логах есть эхм...
> скажем так, сортировка по времени. Очень сильно помогает узнавать с чего
> начались проблемы.Это когда загрузка проходит успешно. Далее, логи ротируются и при достаточно скромных аптаймах нужный фрагмент ко времени фиксирования проблемы мог уже уехать.
Логи и отлаживаемость "на месте" -- это как бэкап и зеркало...
> К слову, у Поттеринга и Ко код написан хорошо и понятно.
И со строками на сях работать проще/компактней/надёжней, чем на шелле, угу.
Возвращаемся всё к тому же: сырую технологию даже не тащат, а назойливо пихают всем подряд, пытаясь использовать в качестве бета-тестеров. Это даже не php, а хуже в квадрате.
ещё хотите про недостатки системд?----
>> теперь бинарные логи. зачем?
> Место на диске экономить, хотя бы.Нет. Для этого придумали logrotate, который успешно gzip-ит (bzip-ит, xz-ит, на ваш выбор) логи уже пару десятков лет. Если хочется, то в обычном rsyslog-е есть потоковое сжатие, чтобы писать логи сразу в сжатом формате, для экономии места. Идея бинарных логов была в том, чтобы превратить их в базу данных, по которой можно делать быстрый поиск, типа "выдайте мне лог такой-то программы за такое-то число". В ответ ему, кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат, есть уже куча готовых программ, которые можно цеплять на обычный syslog, они его проиндексируют, и даже в базу данных могут сложить (навскидку GrayLog2, ElasticSearch, Solr...), и поиск в них намного лучше и фичастее. Но разве поттеринг будет кого-то слушать?
---
systemd — это примерно как взять и заменить автосцепку на всех вагонах на аналогичную, не приносящую никаких бонусов. движения есть, траты колоссальные, людских ресурсов тратится море, но профита НЕТ. при переходе с poll на epoll профит ощутим, при переходе с gcc 2.95 на gcc 3 тоже. а при переходе на systemd геморроя много, а толку нет.
понятное дело, что для людей, которые в возне с линуксом проводят свой досуг, systemd может быть интересен, но для индустрии это жуть.
----
Поттеринг меня раздражает. Он как студент, который не может понять чужого кода на Си и пишет программу полностью, заново, на Python. В примере Си заменить на ядро, а Python на Си. Какие реальные преимущества есть у PulseAudio по сравнению с ALSA? Регулятор громкости всех приложений из одного окна? Да написал бы он себе небольшую утилиту для ALSA - но нет же, не захотел разбираться в коде, сделал прослойку поверх ALSA. Проброс звука по сети? Было в Linux средствами NAS ещё с начала 90-х годов, и багов в этой программе гораздо меньше, чем в PulseAudio, если они вообще есть. Переключение ведущегося разговора с микрофона и колонок на скайпфон без его прерывания? Скайпопроблема. Невозможность поменять порядок звуковых карт без правки конфигов? У меня в Mandriva/SUSE возможно, в остальных не знаю почему нет GUI.
леннарт, поттеринг, ты?
> леннарт, поттеринг, ты?Нет, это другой леннартоборец вас поддерживает :)
> Нет. Для этого придумали logrotate, который успешно gzip-ит (bzip-ит, xz-ит, на ваш
> выбор) логи уже пару десятков лет. Если хочется, то в обычном
> rsyslog-е есть потоковое сжатие, чтобы писать логи сразу в сжатом формате,
> для экономии места. Идея бинарных логов была в том, чтобы превратить
> их в базу данных, по которой можно делать быстрый поиск, типа
> "выдайте мне лог такой-то программы за такое-то число". В ответ ему,
> кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат,
> есть уже куча готовых программ, которые можно цеплять на обычный syslog,
> они его проиндексируют, и даже в базу данных могут сложить (навскидку
> GrayLog2, ElasticSearch, Solr...)Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не решают. Наиболее паршивых проблем две:
1. Неструктурированная запись. syslog by design ориентирован на человека, а не на машинный парсинг, поэтому вместо структурированной записи с именами полей, получается одна текстовая строчка, которую в общем случае может понять только человек. Такое вот сжатие с потерями. В то время как в Journal это сжатие происходит не на стадии записи лога, а на стадии выдачи его человеку. При необходимости, и программы, и человек могут использовать полезную информацию о структуре записи (например, искать сообщения по UUID).
2. Недоверенная информация. В syslog может писать кто угодно и что угодно. Даже из-под nobody можно написать туда такого, что админ будет месяц разбираться.В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный лог (BSM). Так появилась инфраструктура аудита.
Но вопросы структурирования, индексирования информации, быстрого поиска по ней и т.д. актуальны не только для событий безопасности, но и для всех системных событий, так что появление Journal было неизбежно.
> а при переходе на systemd геморроя много, а толку нет.
С точки зрения диванного теоретика - да :)
> понятное дело, что для людей, которые в возне с линуксом проводят свой
> досуг, systemd может быть интересен, но для индустрии это жуть.А вот тырпрайз-админы с нетерпением ожидают RHEL/CentOS/OL 7. В основном из-за Journal, конечно.
> Поттеринг меня раздражает.
Ну и опять поток сознания какого-то хипстера. Скучища...
> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не
> решают. Наиболее паршивых проблем две:
> 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на
> машинный парсинг, поэтому вместо структурированной записи с именами полей, получается
> одна текстовая строчка, которую в общем случае может понять только человек.
> Такое вот сжатие с потерями. В то время как в Journal
> это сжатие происходит не на стадии записи лога, а на стадии
> выдачи его человеку. При необходимости, и программы, и человек могут использовать
> полезную информацию о структуре записи (например, искать сообщения по UUID).Ась? Какое-какое "сжатие с потерями"? Эк Вас приложило-то... А "сжатие происходит не на стадии записи лога, а на стадии выдачи его человеку" - это вообще шедевр! И, к стати, журнал, чем бы он ни был записан (хоть syslog, хоть journal, хоть админом на бумажке) нужен для анализа его человеком. Компьютер, конечно же, может ему в этом помочь, но журнал в текстовом виде в этом случае предпочтительнее, чем в бинарном, поскольку для работы с текстами УЖЕ ЕСТЬ КУЧА ГОТОВЫХ И ПРОВЕРЕННЫХ ИНСТРУМЕНТОВ (grep, awk, perl etc), а для бинарного их (аналоги) нужно создавать с нуля, и ошибок при этом будет немало... Логичный вопрос - зачем терять существующие инструменты ради еще несуществующих и, скорее всего, бажных?
> 2. Недоверенная информация. В syslog может писать кто угодно и что угодно.
> Даже из-под nobody можно написать туда такого, что админ будет месяц
> разбираться.Вы хотите сказать, что в journal писать может не кто угодно? Тогда смысл в этом журнале, если нужная МНЕ (не Вам и не Поттеру, а именно мне на моем компьютере!) программа не может писать в журнал? А если может - то кто мешает мне (ну или тому, кто может запустить програму на этом компьютере) написать в журнал что угодно?
Вы (ну, не лично, а в лице Поттера, или кто там сейчас главный идеолог проекта) пытаетесь проблему безопасности решать инструментом, для этого не предназначеным (системным журналом). Можно, конечно, микроскопом гвозди забивать, но неудобно - молотком значительно удобнее и для пальцев безопаснее.> А вот тырпрайз-админы с нетерпением ожидают RHEL/CentOS/OL 7. В основном из-за Journal,
> конечно.Ну, "тырпрайз-админы" вынуждены "колоться, но жрать кактусы" (С), но ведь жизнь есть и за пределами "тырпрайза" - почему остальные должны "жрать кактусы" за компанию? А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут, остальным тоже вешаться прикажете? А своя-то голова на плечах зачем? Только есть в нее, или все-таки зачем-то еще нужна?
> Ась? Какое-какое "сжатие с потерями"? Эк Вас приложило-то... А "сжатие происходит не
> на стадии записи лога, а на стадии выдачи его человеку" -
> это вообще шедевр!Попробую еще раз, для самых несообразительных: структура записи (какая информация какому полю принадлежит) - это информация. И при выводе в формате /var/log/messages она теряется.
> но журнал в текстовом виде в этом случае предпочтительнее, чем
> в бинарном, поскольку для работы с текстами УЖЕ ЕСТЬ КУЧА ГОТОВЫХ
> И ПРОВЕРЕННЫХ ИНСТРУМЕНТОВ (grep, awk, perl etc), а для бинарного их
> (аналоги) нужно создавать с нуля, и ошибок при этом будет немало...Бинарный формат не требует создания таких инструментов, по определению.
Просто потому, что парсинг текста - это просто попытка восстановить потерянную информацю (отсоединить обратно котлеты от мух, PID от имени бинарника, время от текста сообщения и т.д.). В бинарном формате их не нужно разделять, потому что их никто не смешивал.> Вы хотите сказать, что в journal писать может не кто угодно? Тогда
> смысл в этом журнале, если нужная МНЕ (не Вам и не
> Поттеру, а именно мне на моем компьютере!) программа не может писать
> в журнал? А если может - то кто мешает мне (ну
> или тому, кто может запустить програму на этом компьютере) написать в
> журнал что угодно?Записать в журнал вы можете все, что угодно. Но только от своего имени (UID, GID, session ID). И столь ненавидимый вами бинарный формат позволит легко отфильтровать это.
А при записи в syslog регистрируется не UID программы (протокол syslog это не поддерживает), а тот UID, который сама программа изволит сообщить. Поэтому даже nobody может писать от имени рута.
> А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут
Скорее, завтра станут вешаться противники systemd, в знак протеста :)
> Попробую еще раз, для самых несообразительных: структура записи (какая информация какому
> полю принадлежит) - это информация. И при выводе в формате /var/log/messages
> она теряется.Вот, для сравнения, несжатый вариант
Tue, 2012-10-23 23:51:38 CEST
PRIORITY=6
SYSLOG_FACILITY=3
_MACHINE_ID=a91663387a90b89f185d4e860000001a
_HOSTNAME=epsilon
_TRANSPORT=syslog
SYSLOG_IDENTIFIER=avahi-daemon
_COMM=avahi-daemon
_EXE=/usr/sbin/avahi-daemon
_SYSTEMD_CGROUP=/system/avahi-daemon.service
_SYSTEMD_UNIT=avahi-daemon.service
_SELINUX_CONTEXT=system_u:system_r:avahi_t:s0
_UID=70
_GID=70
_CMDLINE=avahi-daemon: registering [epsilon.local]
MESSAGE=Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53.
_BOOT_ID=5335e9cf5d954633bb99aefc0ec38c25
_PID=27937
SYSLOG_PID=27937
_SOURCE_REALTIME_TIMESTAMP=1351029098747042И сжатый:
Oct 23 23:51:38 epsilon avahi-daemon[27937]: Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53.
Несжатый вариант можно спокойно фильтровать по любому полю, а сжатый сначала надо распарсить, чтобы привести вновь в некоторое подобие несжатого.
> А при записи в syslog регистрируется не UID программы (протокол syslog это
> не поддерживает), а тот UID, который сама программа изволит сообщить. Поэтому
> даже nobody может писать от имени рута.http://blog.gerhards.net/2011/11/trusted-properties-in-rsysl... просвещайся.
> http://blog.gerhards.net/2011/11/trusted-properties-in-rsysl... просвещайся.Оттуда:
> The idea is rooted in the journald proposal
:)
А между прочим кто сказал, что поступающая в журнал инфа должна укладываться в прокрустово ложе представлений Леонардо о нормализации?И почему бы не хранить данные в NoSQL DB?
И с какого перепуга Леонардо смешал в кучу нормализацию данных (которая очевидно в журнале никому не упала) и бинарный формат, который возможно кому-то и понадобится? Между этими понятиями, если что, знак равенства не стоит!
> И почему бы не хранить данные в NoSQL DB?считай, что бинарный лог и есть такая DB.
Наивный вопрос имею: а почему бы не считать такой БД обычный текстовик в формате "ключ-значение"?
можно и так считать, под 'NoSQL БД' попадает всё что угодно
Тогда последний наивный вопрос: а не проще ли было бы прикрутить к rsyslog (как вариант) NoSQL backend на вкус админа хоста и расслабится? На все-про-все пол-часа работы...
> а не проще ли было бы прикрутить к rsyslog (как вариант) NoSQL backendсислог не предоставляет равноценный интерфейс приложению. Mеняется не только способ хранения, но и API между логгером и сервисом (+ некоторые метаданные из приложения). Правда, текущее API сделано убоговато и не раскрывает всего потенциала технологии.
[сообщение отредактировано модератором]
> Наивный вопрос имею: а почему бы не считать такой БД обычный текстовик в формате "ключ-значение"?Потому что у него нет индексов для быстрого лукапа в основном. Ну и потому что он неэффективен для хранения всего что отличается от текста. Например IPv4 занимает в бинарном виде 4 байта. А сколько он займет в виде текста? Ах, вплоть до 15 байтов? И как вам перспектива получить лог не на 4 гига а на 15? Ну, если немного отмасштабировать.
А потом будет очень круто, когда 15-гиговый лог без индекса надо будет целиком лопатить грепом.
На самом деле, вы немножко забегаете вперед: сначала надо условится о том "что" храним, а уж потом думать о том "как" храним.О том "что храним". Если мы все согласны с тем, что журнал призван хранить массив слабо-нормализованной информации, то изделие из мастерской Леонардо нам *уже* не подходит, вне зависимости от того в каком формате это все хранится.
Теперь о том, "как" хранить. Есть разные случаи и разные потребности: кому-то и индексы будут не нужны, а кому-то потребуются множественные параллельные запросы в стиле map-reduce. ОК, ну так для этой цели как раз и нужна архитектура фронтэнд-бакэнд, причем в качестве бакэнда должна иметь возможность выступить *любая* NoSQL СУБД. От текстовика, до промышленных МонгоДБ и ОриентДБ. Но, насколько я понимаю, изделие Леонардо этого не умеет и работает строго со своим хранилищем. Так что и тут неувязочка.
Подытоживая: возможно, rsyslog и иже с ними и устарели (не буду спорить, хотя спорить есть о чем), но и то что пихает г-н Поттеринг - это не то. ИМХО, это сильно урезанная и пропущенная через призму его мнения версия того что надо. И ничего другого от него ждать и не стоит: практически все его программы очень неопрятны и размазаны архитектурно. Риск их применения ну очень велик, а профит напротив - ничтожен.
> Попробую еще раз, для самых несообразительных:Вы бы сами для начала перестали путать "формат /var/log/messages" и RFC 3164/5424.
> Бинарный формат не требует создания таких инструментов, по определению.
Сказочник.
> Просто потому, что парсинг текста - это просто попытка восстановить потерянную
> информацю (отсоединить обратно котлеты от мух, PID от имени бинарника, время от
> текста сообщения и т.д.). В бинарном формате их не нужно разделять,
> потому что их никто не смешивал.Вопрос в надежде на то, что это был всё-таки помрачённый User294: зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?
>> А если завтра "тырпрайз-админы" возьмут веревки и дружно вешаться станут
> Скорее, завтра станут вешаться противники systemd, в знак протеста :)Завтра он начнёт интересными пакетиками с сетью обмениваться, что-то мне подсказывает.
> зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?Ну и зачем ?
>> зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?
> Ну и зачем ?...когда всё решается высокоуровневыми запросами по структурированным данным, ага... ;-)
Хранимые процедуры придуманы для реализации бизнес-логики, когда скорость критична или когда необходимо преобразование данных прямо в базе. И что?
> И что?Если мне не изменяет склероз по мотивам давно уж прочтённого Дейта, то изначально высоколобые теоретики предполагали, что всем(tm) будет достаточно языка четвёртого поколения.
Жизнь оказалась заковыристей.
Так и тут -- когда заливают про "всем хватит полутораста высокоуровневых ручек [с прибитой гвоздями семантикой]", купиться на это может в основном недостаточно уделивший внимание предыдущим сериям молодняк.
При этом и ручки нужны, и SQL полезен -- спору нет. В отличие от людей с табличным или псевдосистемным подходом ко всему подряд.
> > зачем в РСУБД хранимые процедуры придумали -- сами сообразите или подсказать надо?
>
> Ну и зачем ?В процессе отработки кошерного реляционного запроса легко получаются многомерные массивы нехилого объема. И тогда придумать sql clause, который engine может переварить становится нетривиально и он (clause) сильно зависит от engine (т.е. формально переносимо, фактически --- нет).
1) Структурированный лог это замечательно.
2) Двоичный лог это просто глупость.
3) "Доверенное" логгирование это палка о двух концах, поскольку добавляет в систему еще одну Точку Отказа Всего.
> Все эти костыли по-своему замечательны, но проблем дизайна протокола syslog они не
> решают. Наиболее паршивых проблем две:
> 1. Неструктурированная запись. syslog by design ориентирован на человека, а не на
> машинный парсинг, поэтому вместо структурированной записи с именами полей, получается
> одна текстовая строчка, которую в общем случае может понять только человек.
> Такое вот сжатие с потерями. В то время как в Journal
> это сжатие происходит не на стадии записи лога, а на стадии
> выдачи его человеку. При необходимости, и программы, и человек могут использовать
> полезную информацию о структуре записи (например, искать сообщения по UUID).Все программисты сразу кинулись переписывать программы под journald ?
> 2. Недоверенная информация. В syslog может писать кто угодно и что угодно.
> Даже из-под nobody можно написать туда такого, что админ будет месяц
> разбираться.А вот ненадо ставить права на лог 777.
> В UNIX эту проблему решили много лет назад, введя специальный защищенный бинарный
> лог (BSM). Так появилась инфраструктура аудита.
> Но вопросы структурирования, индексирования информации, быстрого поиска по ней и т.д. актуальны
> не только для событий безопасности, но и для всех системных событий,
> так что появление Journal было неизбежно.вы действительно хотите индексировать логи на боевом сервере?
Как там у journald с удаленными логами, не стриминг по http а именно удаленная запись логов.
> вы действительно хотите индексировать логи на боевом сервере?А вы действительно используете syslog для логирования запросов, к скажем, высоконагруженному nginx? Мне кажется, тут безальтернативно - либо писать их в файл самим nginx'ом, что и делается в 90 из 100 инсталляций, либо, если есть реальная необходимость, то докупить озу и хранить их какое-то время в рамдиске, а потом сливать куда нибудь по сети. Можно ещё писать на отдельный диск, да, должно быть не очень печально в плане нагрузки. Впрочем, это меня уже в сторону понесло, основная мысль - писать быстро генерирующиеся большими пачками логи что в syslog, что в journal - глупость. А для системных логов, я практически уверен, переубедите меня тестами или примерами, существенной разницы и нет.
> Как там у journald с удаленными логами, не стриминг по http а
> именно удаленная запись логов.Не знаю. Но вообще, journald более чем спорная штука, тут не поспоришь.
> А вот ненадо ставить права на лог 777.А вот не надо считать будто это убирает проблему. Вызов спец. тулзы никто не отменял.
> Идея бинарных логов была в том, чтобы превратить их в базу данных, по которой можно делать быстрый поискидея бинарных логов в другом, ~ стандартизированное навешивание метаданных на логгируемый текст. Можно, конечно, сделать тоже самое и в текстовых форматах. Технологически текстовый формат значительно сложнее бинарного в реализации. Чтобы представить какое это адище можно посмотреть как это делают с хml.
Проблема текущих текстовых логов это отсутствие вообще какой-либо стандартизации представления данных. Т.е. для каждой админской настройки нужно херачить свои регэкспы для выдёргивания метаданных.
> типа "выдайте мне лог такой-то программы за такое-то число"
суть этого не быстрый поиск, а фильтрация по метаданным. И быть там может не только имя программы, а и другие атрибудты которых в стандартном логгере просто нет.
> В ответ ему, кажется, автор rsyslog-а писал, что для этого не нужен бинарный формат, есть уже куча готовых программ, которые можно цеплять на обычный syslog, они его проиндексируют
Есть некоторые костыли. Ибо поблема, ещё раз повторю, не в поиске.
> systemd — это примерно как взять и заменить автосцепку на всех вагонах на аналогичную, не приносящую никаких бонусов. движения есть, траты колоссальные, людских ресурсов тратится море, но профита НЕТ. при переходе с poll на epoll профит ощутим, при переходе с gcc 2.95 на gcc 3 тоже. а при переходе на systemd геморроя много, а толку нет
ваша проблема в том, что вы ничего не видите дальше своего носа и душой прикипели к "уютным" инструментам из своего юношеского прошлого. Т.е. состарились и превратились в пенсионера в негативном смысле этого слова.
бонусы от systemd-подобной технологии могут быть видны только через длительное время, пока большая часть разработчиков сервисов не станут пользоваться новыми фичами.
> Какие реальные преимущества есть у PulseAudio по сравнению с ALSA?
например, ALSA умеет _нормально_ делать только hwmix и не умеет софтверно. Если перевести на более привычный язык, ALSA не умеет работать с несколькими приложениями если драйвер этого не позволяет.
> Регулятор громкости всех приложений из одного окна?
наоборот же, у ALSA один регулятор громкости для всех каналов, у PA персональные для клиента. ALSA не даёт однотипныъ фич приложениям на всём железе, потому всегда будет нужен аналог PA.
> Да написал бы он себе небольшую утилиту для ALSA - но нет же, не захотел разбираться в коде
в случае с PA он не захотел быдлокодить и костылить. Архитектурно на ALSA'у нельзя нормально навесить весь подобный функционал.
> понятное дело, что для людей, которые в возне с линуксом проводят свой досуг, systemd может быть интересен, но для индустрии это жуть.
это, между порчим, придумал не Поттеринг, а индустрия в лице SUNа и solaris/smf. Откуда он и упёр многое в системд. Теперь индустрия в лице красношапки хочет похожее видеть у себя.
> суть этого не быстрый поиск, а фильтрация по метаданным.Внимание, вопрос: когда она начинает быть нужна?
> Есть некоторые костыли. Ибо поблема, ещё раз повторю, не в поиске.
Для *проблемы* есть более вменяемые решения, уже как-то приводил списочек. А эти полумеры -- они в тривиальных случаях жизнь затрудняют, в сложных... тоже затрудняют, т.к. стыковать сложнее (по крайней мере здесь и сейчас).
> бонусы от systemd-подобной технологии могут быть видны только через длительное время,
> пока большая часть разработчиков сервисов не станут пользоваться новыми фичами.Зачем тогда такая спешка с запихиванием всех на systemd всеми правдами и неправдами?
> например, ALSA умеет _нормально_ делать только hwmix и не умеет софтверно.
JFYI, dmix знаю куда больше времени, чем Вас читаю.
> наоборот же, у ALSA один регулятор громкости для всех каналов, у PA
> персональные для клиента. ALSA не даёт однотипныъ фич приложениям на всём
> железе, потому всегда будет нужен аналог PA.А если мне не надо? (и лишние wakeups тоже не хочу)
>> суть этого не быстрый поиск, а фильтрация по метаданным.
> Внимание, вопрос: когда она начинает быть нужна?Когда кто-то идет изучать логи, а не просто спускает их в /dev/null в очередной раз. Ну да, если логи просто спускать в /dev/null - их можно в любом формате писать. А вот если хочется проанализировать чем вообще машина занимается - тут текстовые логи начинают вызывать бурную икоту. За отсутствием там каких либо индексов обработка логов сколь-нибудь нагруженного сервака за сколь-нибудь существенный период занимает уйму времени. Потому что единственный способ - прочитать все логи и посмотреть нет ли в каждой записи интересующих значений. Что как-то тормознуто на больших объемах логов.
> тоже затрудняют, т.к. стыковать сложнее (по крайней мере здесь и сейчас).
Кому-то сложнее, кому-то проще. Вот рынок и решит кому как проще оказалось.
> Зачем тогда такая спешка с запихиванием всех на systemd всеми правдами и неправдами?
Никто к лично вам не придет отбирать у вас sysvinit. Просто если админам в целом окажется более удобно нечто типа systemd, вы просто останетесь без пользователей дистра. Это будет вполне честным вариантом.
> А если мне не надо? (и лишние wakeups тоже не хочу)
А вы знаете, даже фирма Нокия, которую wakeups интересовали поболее любого альта, раз так в эн, ибо у них батарейные девайсы, с питанием от хиленького мобилочного акку, в свое время вполне успешно применила пульсаудио на мобильном телефоне. И вы знаете, они там натурально поюзали разные громкости звука для разных приложений. Так что уровень громкости рингтона - не то же самое что уровень громкости звука в плеере и не то же самое что громкость разговора во время звонка, например. Что вообще-то чертовски логично и ожидаемо.
По поводу чего ваши претензии смотрятся, мягко говоря, очень натянутыми. А называя вещи своими именами - вы их откровенно высосали из пальца для оправдания своей персональной упертости.
> если админам в целом окажется более удобно нечто типа systemd,
> вы просто останетесь без пользователей дистра.Пользователям всё равно, что удобнее админам.
Но и с системд может произойти прямо до наоборот.> даже фирма Нокия применила пульсаудио на мобильном телефоне
Кирпичи от Нокиа тоже умели это, где пульсаудио не может быть по-определению.
> они там поюзали разные громкости звука для разных приложений
dmix + softvol или где-то enable control keys
Что дефолтно часто не активировано и надо подтолкнуть.
Если ситуацию нельзя довести до подобного, то это уже проблемы клозет сорс.
там вообще несколько через кое-что сделано. система жестоко завязана на dbus и gconf, причем без особой на то надобности.
> А вы знаете, даже фирма Нокия, которую wakeups интересовали поболее любого альта,
> раз так в эн, ибо у них батарейные девайсы, с питанием
> от хиленького мобилочного акку, в свое время вполне успешно применила пульсаудио
> на мобильном телефоне.и это был редкостный идиотизм, да. учитывая, что при этом нокия не дала исходников некоторых важных приложений — нормально выпилить пульсосрань не получается до сих пор. ты ведь — без сомнения — знаешь, что на N900 mplayer из-за пульса иногда подтормаживает? как, без сомнения, знаешь, что у новых пульсов другой сетевой протокол, а старый пульс на N900 апгрейднуть нельзя, ибо некоторый софт (см. выше), поэтому хвалёная «передача звука по сети» тоже не работает. это так, навскидку. конечно, доблестному китайскому комсомольцу подобные вещи в кайф. а мне вот — нет, потому что единственное, из-за чего можно было с трудом терпеть пульс — передача звука по сети — не работает.
> Зачем тогда такая спешка с запихиванием всех на systemd всеми правдами и неправдами?Зачем оно RH имхо очевидно, а насчет всех это вопрос к ним же. Должно быть или из-за отличного качества продукта, или из-за неудовлетворительной квалификации затаскивающих это как дефолтный init. Толсто, да, но других причин честно не придумывается.
> есть уже куча готовых программ, которые можно цеплять на обычный syslog,
> они его проиндексируют, и даже в базу данных могут сложить (навскидку
> GrayLog2, ElasticSearch, Solr...), и поиск в них намного лучше и фичастее.Ха-ха! Давай по пунктам:
- Solr
это индексатор. Сам по себе ничем не ценен- ElasticSearch
то же самое- Graylog2
Начнем с того, что это сетевой сервер на джаве, требующий для работы внешний индексатор (еще один демон) и кластерную распределенную СУБД (монга).
И это мы еще веб-морду не поставили, а она требует ruby on rails, rack-compatible application server, и полновесный http-демон.То, что ты предложил, предназначено для сбора логов с большого количества серверов в промышленных масштабах на выделенный под эти цели кластер.
journal же нужен для похожей задачи, но только в рамках одной машины. Это совершенно разные области!
> То, что ты предложил, предназначено для сбора логов с большого количества
> серверов в промышленных масштабах на выделенный под эти цели кластер.
> journal же нужен для похожей задачи, но только в рамках одной машины.
> Это совершенно разные области!Внимание, вопрос: зачем мне "то же самое, только в рамках одной машины"?
А что применить из уже работающего крупнокалиберного по задачам, где _действительно_ есть смысл в риторике, которую слышу в пользу journal -- и так знаю.
sata_nv.parallel_scan=1
> sata_nv.parallel_scan=1Хм. А тыщу LVM-томов оно тоже ускорит (это не возражение, а именно вопрос)?
залучит все
> залучит всеВ смысле - залучит?
Вот прочитал комментарии и подумал. Знаете, что самое забавное. Комментаторы столько энергии и страсти тратят на критику/защиту systemd, как будто от этого что-то зависит. А между тем весь этот процесс идет независимо от них. Я таки защищаю всех тех, кто просто делает свое дело.
> Вот прочитал комментарии и подумал. Знаете, что самое забавное. Комментаторы столько энергии
> и страсти тратят на критику/защиту systemd, как будто от этого что-то
> зависит. А между тем весь этот процесс идет независимо от них.
> Я таки защищаю всех тех, кто просто делает свое дело.Пока платят бабки чтоб процесс то не шел?
Менеджер дал задание программер написал, как написал че написал всем пофиг.
Главное это продать, прорекламировать и продать.
Не индусские неасиляторы баша стоят дешевле, это позволяет сэкономить.
Есть проблемы добро пожаловать в службу поддержки redhat.
Дальше можно не писать и так понятно зачем systemd нужен и кому.
Можно было вообще не писать с самого начала. Столько энергии в пустоту ущло.
> Пока платят бабки чтоб процесс то не шел?Да, кому-то платят бабки за то, чтобы процесс развития opensource не шёл. Но большинство - идейные, запуганные перспективами. Как когда-то пугали коммунизмом, что всё задушит и отберёт, так и сейчас опенсорцом.
Люди пишут злобные комментарии не от хорошей жизни. Они просто выросли в таком мире, на такой культуре.И не имеет значение, хорошее это или плохое. Люди пишут комментарии по тому, что более популярно. Потому что более резонансно. Кто-то от таких комментариев ломается (разработчики Gnome3), кто-то с большим трудом через них пробивается, постоянно оправдываясь (systemd), а кто-то просто делает то, что считает нужным, так, как считает нужным (лидеры ядра Linux, системы OpenBSD).
Так выпьем же за то, чтобы всё это делало нас только сильнее.
Ай да Леннарт, ай да сукин сын!
а кто эта женщина в очках?
> а кто эта женщина в очках?Ах вон оно что! Я то думаю, что это у WOT'а сервера постоянно отваливаются и тех. работы регулярнее появления тандема на экране. Так это поттеринг.
Я не ошибся там упомянуты сервера с тысячами дисков?
> Я не ошибся там упомянуты сервера с тысячами дисков?Сервак с 40 дисков собрал вообще какой-то индивид с хабры. На коленке и вообще с виндой. По поводу чего не понятно, чего бы вдруг пингвину не работать с сотнями или даже тысячами дисков.
Ну как бы с того кто подключить их будет ну очень проблемно. Просто жуть как проблемно. То есть в теории я не отрицаю такого, но на практике бред.
Adaptec RAID 72405 ASR-72405 Single PCI-E x8, 24-port SAS
24*3+6=78
ну по крайней мере 78 подрубить можно, и еще pci-e x1 остануться.
> Adaptec RAID 72405 ASR-72405 Single PCI-E x8, 24-port SAS
> 24*3+6=78Это если без экспандеров. С другой стороны -- а оно честно не затыкается при 24 дисках?
Вопрос номер раз, почему systemd не была написана раньше?
Тот кто может такую написать люди умные и им она нафиг не нужна.
Те кто не могут, поклоняться поттерингу.
ну да, примерно потому же, почему двухпанельных файловых менеджеров не так много (мёртвые проекты и проекты в анабиозе не в счёт). именно потому, что пока он автору нужен, то автор не очень хорошо программирует. а когда автор хорошо программирует — уже и не нужен.
Centos 6.3, кусочек из killproc():# Kill it.
if [ -n "$pid" ] ; then
[ "$BOOTUP" = "verbose" -a -z "${LSB:-}" ] && echo -n "$base "
if [ -z "$killlevel" ] ; then
if checkpid $pid 2>&1; then
# TERM first, then KILL if not dead
kill -TERM $pid >/dev/null 2>&1
usleep 100000
if checkpid $pid && sleep 1 &&
checkpid $pid && sleep $delay &&
checkpid $pid ; then
kill -KILL $pid >/dev/null 2>&1
usleep 100000
fi
fi
checkpid $pid
RC=$?
[ "$RC" -eq 0 ] && failure $"$base shutdown" || success $"$base shutdown"
RC=$((! $RC))Кусочек из status()
status() {
local base pid lock_file= pid_file=
# Test syntax.
if [ "$#" = 0 ] ; then
echo $"Usage: status [-p pidfile] {program}"
return 1
fi
if [ "$1" = "-p" ]; then
pid_file=$2
shift 2
fi
if [ "$1" = "-l" ]; then
lock_file=$2
shift 2
fi
base=${1##*/}Про инит скрипты musqld вообще молчу. Человек, который считает что это правильно и удобно, определённо не дружит с головой
а что не так собственно? алгоритм не красивый? или буковки незнакомые?
Дебильные непараметризованные sleep и usleep, usage в status не описывает реально его функционал и прочее и прочее. Это адов бардак, писавшийся разными людьми с разными подходами, сплошные костыли и workaround'ы. Мне по работе приходится постоянно в этом центосном навозе копаться и я очень очень тоскую по systemd на своих личных компах и ноутбуках. А ещё приходится писать init'ы для использования с initctl от upstart и прочую херь, которая в systemd пишется в три-пять простых и понятных строк
Странные у вас аргументы про костыли и подходы, systemd внутри тоже не блещет фердипердозностью.
> Странные у вас аргументы про костыли и подходы, systemd внутри тоже не
> блещет фердипердозностью.Чего странного? Я представил энтерпрайзный быдлокод, объяснил что мне в нём не нравится. И, в отличие от, для использования systemd мне в его код лезть нет необходимости. Он экономит моё время. А если systemd внутри не блещет "фердипердозностью", так я только рад: не уверен в необходимости такого блеска.
Это вы себя программируете словом "быдлокод"? Объясните чем тогда отличается изменение под свои нужды "быдлокода" и "быдлоконфига" для systemd?
> Это вы себя программируете словом "быдлокод"? Объясните чем тогда отличается изменение
> под свои нужды "быдлокода" и "быдлоконфига" для systemd?Временем, коллега. Разбирание в кривых (а их реально много) init скриптах есть бесполезная трата времени. Конфиг сервиса для systemd представляет собой несколько простых строчек и понятен с первого взгляда. Вероятность ошибок снижается, эффективность работы повышается. Если это не очевидно - увы.
Вы теплое с мягким не путайте. Несколько строчек будет и в скрипте для запуска среднестатистического сервиса. Вы попробуйте сделать конфиг под systemd с условиями запуска, допустим, по времени запуска или версии ядра..
> Вы теплое с мягким не путайте. Несколько строчек будет и в скрипте
> для запуска среднестатистического сервиса. Вы попробуйте сделать конфиг под systemd с
> условиями запуска, допустим, по времени запуска или версии ядра..Вот удивляют меня люди, не читающие документацию, но активно при этом спорящие. В описании сервиса в вашем случае пригодятся директивы Requires= After= ExecStartPre= а также секция [Timer]. Если, конечно, какие-то причины не позволяют использовать cron например
вот-вот! в конечном итоге для нетривиальной задачи ваш конфиг выродится в указание путей к скриптам...
> вот-вот! в конечном итоге для нетривиальной задачи ваш конфиг выродится в указание
> путей к скриптам...Демагог же. К чёрту авто, в нетривиальном случае придётся воспользоваться лошадью.
в тривиальном случае достаточно самоката. в нетривиальном — всё равно самому байк собирать. а непонятная конструкция, у которой 100500 ручек, но реально полезны только манипуляторы, которыми она может пощекотать механизмы, которые пыталась заменить — действительно, вряд ли нужна.
> Демагог же. К чёрту авто, в нетривиальном случае придётся воспользоваться лошадью.Ну-ну, софизмы до сего момента звучали от вас.
> И, в отличие от, для использования systemd мне в его код лезть нет необходимости.А нафига тогда полез в killproc()?
>> И, в отличие от, для использования systemd мне в его код лезть нет необходимости.
> А нафига тогда полез в killproc()?Разгребал разнообразные глюки при shutdown'е сервера
Ай а ссылку на багрепорт можно?
> Ай а ссылку на багрепорт можно?Сервисы внутрикомпанейские, собственной разработки, поэтому и багзилла внутренняя ;) Просто когда дебажишь свои поделия, приходится разбираться в стандартных библиотеках init-скриптов. А оттуда выплывает всякое...
>Centos 6.3, кусочек из killproc():глянь на код CRUX, Slackware. От людей и для людей.
>>Centos 6.3, кусочек из killproc():
> глянь на код CRUX, Slackware. От людей и для людей.CRUX некторое время юзал, потом ушёл на анлогичный lunar. В целом про инициализацию CRUX'а согласен: человеками и для человеков ;-)
> CRUX некторое время юзал, потом ушёл на анлогичный lunar.Кстати, а в crux есть поддержка нескольких репозиториев? В lunar-то точно нет (поэтому я и использую до сих пор SMGL).
Похоже таки есть. Но там нет аналога emerge --depclean, увы.
"Раньше мой линукс поднимался медленно, но когда я попробовал systemd мой линукс стал подниматься гораздо быстрее..."
<<
>>
без systemd, еще быстрее
Спасибо! Интересно было послушать, жаль что слайдов во втором видео не видно.
В новости есть ссылка на страницу с докладами к конференции, а там есть ссылки на все презентации.
Разработчики ненужноd: загрузка с ненужно оказалась быстрее загрузки без ненужно