Разработчики проекта Debian утвердили (https://lists.debian.org/debian-devel-announce/2015/03/msg00...) дату выпуска Debia 8.0 "Jessie". Релиз намечен на 25 апреля. Сообщается, что дата может быть изменена только в случае выявления действительно критических проблем. В настоящее время остаются неисправленными 44 RC-ошибки (https://udd.debian.org/bugs/?release=jessie_and_sid&merged=i...) в ключевых пакетах и 23 ошибки (https://udd.debian.org/bugs/?release=jessie_and_sid&merged=i...) в обычных пакетах (если проблемы не будут решены до 18 апреля, данные пакеты не войдут в состав релиза).URL: https://lists.debian.org/debian-devel-announce/2015/03/msg00...
Новость: http://www.opennet.me/opennews/art.shtml?num=41944
ура! ждем релиза!
>#781544 firmware-b43-installe breake 2015-03-31Ой ой!
Там ошибка только при обновлении и то мелкая. Просто заигнорят её и опишут способ решения в release notes.
firmware-b43-installer... выпускайте так!
Новость случайно не с Камчатки?
Лучший дистрибутив. Ждём релиза, чтобы с него обновиться до testing.
> Лучший дистрибутив.Был.
Теперь даже вот эта порнография
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913
- не RC баг.
> ● (green) ssh.service - OpenBSD Secure Shell server
> Active: failed (Result: start-limit) since Mo 2015-03-30 00:59:07Думал это я один не так понимаю статусы systemd. Кружок зеленый и при этом failed.
Доктор, ЧЯДНТ? У меня Джесси прекрасно работает с sysvinit. И системГ вытравливается, если третьегномом не болеешь.
>Доктор, ЧЯДНТ? У меня Джесси прекрасно работает с sysvinit. И системГ вытравливается, если третьегномом не болеешь.У вас шизофрения на фоне некрофилии.
>>Доктор, ЧЯДНТ? У меня Джесси прекрасно работает с sysvinit. И системГ вытравливается, если третьегномом не болеешь.
> У вас шизофрения на фоне некрофилии.Доктор, а по ченджлогу
http://metadata.ftp-master.debian.org/changelogs//main/s/sys...
Вы диагностируете так же удивительно, как по форумам? Осените нас Вашим Прозрением, просим!
> Думал это я один не так понимаю статусы systemd. Кружок зеленый и
> при этом failed.Судя по всему - он стартанул. Но - внезапно завершился по какой-то ошибке. После чего, его несколько раз перезапустили. Но это не помогло. Включился лимит рестартов сервиса - потому и start limit, видимо.
Что система инициализации должна сообщить? Старт успешен. Неуспех наступает немного опосля, когда сервис вырубается по какой-то своей причине.
Демагогичненько )
Это как с эвакуацией авто: "Что считать началом эвакуации? Логично - начало движения эвакуатора с погруженным авто. - Нее! Давайте считать началом - зацепление троса за бампер. - ОК!".
Врете вы всё. В России такого случая не могло произойти т.к. С 1961 года началом считается "Поехали!"
> Врете вы всё. В России такого случая не могло произойти т.к. С
> 1961 года началом считается "Поехали!"Ты гонки-то с американами и карман хапуг при гаёвнях не путай, Родину не позорь.
Похоже, Вы давно не были в России!
> Что система инициализации должна сообщить?Что сервис лежит. User294, Вы же тут рвали всех за системдэшный мониторинг на британский флаг -- неужели сами при этом вообще никогда и ничего под таковой не загоняли?
# monit summary | grep sshd; pidof sshd
Process 'sshd' Running
File 'sshd_bin' Accessible
File 'sshd_rsa_key' Accessible
File 'sshd_dsa_key' Accessible
File 'sshd_rc' Accessible
25939 25929 24279 24274 18739 18734 16629 16624 9348
Вы читать умеете ?В конфиге sshd есть ошибки и при запуске он падает, systemd видит что sshd упал и перезапускает его снова и снова.
monit в такой ситуации будет вести себя совершенно также.
> systemd видит что sshd упал и перезапускает его снова и снова.феерично!
> В конфиге sshd есть ошибкиРаньше sysvinit просто проверял это и отказывался запускать сервис
за бессмысленностью. А теперь мы будет рестартовать его, в ожидании
когда добрая фея в 100500-й раз придет и поправит конфиг.Кстати, они и socket-activation врубили по-умолчанию, как в федоре. Вот так -
отредактировал конфиг, перезапустил сервис, а об опечатке узнаешь только
когда в следующий раз ткнешься на сервер.Думал баг написать, но, наверное, это уже все бессмысленно.
> monit в такой ситуации будет вести себя совершенно также.
Дубина. Монит тоже отстанет но он и повесит соответствующую
_красную_ табличку (failed). Есть разница?
> Раньше sysvinit просто проверял это и отказывался запускать сервис
> за бессмысленностью. А теперь мы будет рестартовать его, в ожидании
> когда добрая фея в 100500-й раз придет и поправит конфиг.Если ты не заметил - там в баге сделали точно такое же поведение, дописав в prestart такую проверку. ВНЕЗАПНО!
> Думал баг написать, но, наверное, это уже все бессмысленно.
Тебе писать баги в системд - нос еще не дорос. Когда у тебя будет в 5 раз меньше гонора и в 5 раз больше знаний - тогда и приходи.
> Дубина. Монит тоже отстанет но он и повесит соответствующую
> _красную_ табличку (failed). Есть разница?Так systemd тоже табличку в конце концов вывесил. Хоть и не совсем эстетично. Но если кто тyпой и слепой как котенок, там в баге sshd -t в prestart добавили :)
>> Раньше sysvinit просто проверял это и отказывался запускать сервис
>> за бессмысленностью. А теперь мы будет рестартовать его, в ожидании
>> когда добрая фея в 100500-й раз придет и поправит конфиг.
> Если ты не заметил - там в баге сделали точно такое же
> поведение, дописав в prestart такую проверку. ВНЕЗАПНО!В баге пока только в одном месте некоторые ковыряются... И жалуются на
неправильный sshd. А сделано - ничего, баг даже не RC.>> Думал баг написать, но, наверное, это уже все бессмысленно.
> Тебе писать баги в системд - нос еще не дорос.Да уж куда мне, сиволапому, в systemd - мне б в Debian. Раньше как-то
"доростал", лет десяток с хвостиком. А теперь, да. Плохи для Debian те,
кто сделал Debian - Debian'ом...> Когда у тебя будет в 5 раз меньше гонора и в 5 раз
> больше знаний - тогда и приходи.Вы от имени кого, собственно, приглашаете? Вы DD, или отношение
к проекту имеете чуть менее чем никакого?>> Дубина. Монит тоже отстанет но он и повесит соответствующую
>> _красную_ табличку (failed). Есть разница?
> Так systemd тоже табличку в конце концов вывесил. Хоть и не совсем эстетично.Нет. Когда статус success, "green OK", это не просто "эстетично" - это просто
зашибись. Нужно только привыкнуть, что полезная информация засунута создателями
systemd подалее в задний проход. И дезинформируют пользователей они просто
по пословице, ну "чтобы жизнь медом не казалась".> Но если кто тyпой и слепой как котенок, там в баге sshd -t в prestart добавили :)
Да, я настолько тупой котенок, что не вижу что в баге чего-то "добавили". Там
идет обсуждение, critical/serious приоритет багу никто не сделал, даже pending не
повесили, в знак того что решение найдено.
А SysV-init и BSD-init просто в stderr вывалят мессагу от демона, что в конфиги ахинея какая-то. Офуенный прогресс у поттеринголюбов.
И не говорите.
Я обычно syslog смотрю, после редактирования конфигов и перезапуска.
> Я обычно syslog смотрю, после редактирования конфигов и перезапуска.Только вот в сислог stderr программ писаться, мягко говоря, не обязан. И все это делает отладку обломавшегося запуска в sysv init не слишком пресный - если надо это логгить, чаще всего ты идешь и дописываешь этот логгинг сам. А еще сервисы занимаются фееричным костылированием с несколькими форками и прочая. Наф-наф-наф эту замшелую и костыльную системную механику. Поттер все это сделал прямее и логичнее, что бы там ни шипели его ненавистники.
> А SysV-init и BSD-init просто в stderr вывалят мессагу от демона,При том на половине систем этого никто никогда не увидит, пардон. То ли дело системдэ - честно запишет ошибку в лог, где ее можно будет еще и найти. То чего от sysv init хрен дождешься, и то что апстарт делает по жизни криво.
> Офуенный прогресс у поттеринголюбов.
Если с системдой разобраться - он хороший тул, просто надо усвоить что при этом надо лог смотреть. Вот там ошибка почти наверняка есть. В отличие от сферического stderr в вакууме, который может быть фиг знает где :). Поцтр как раз решил хоть немного окультурить этот пи..ц и сделал... ну, получше чем те кто делал это до него.
> как раз решил хоть немного окультурить этот пи..ц и сделал...
> ну, получше чем те кто делал это до него.Вы заслушали мнение админа локалхоста, который не сталкивался с тем, что давно уж сделано и работает по части агрегирования логов.
Вот как люди берутся столь беспардонно обобщать, вроде бы имея возможность оценить уровень своей некомпетентности и границы, соответственно, компетентности?
> Вы заслушали мнение админа локалхоста, который не сталкивался с тем, что давно
> уж сделано и работает по части агрегирования логов.Спасиб, видели мы как это сделано. У поттера как-то логичнее. И система относительно автономна, если надо, и предоставит определенные удобства админу даже на локалхосте, в дефолтной напрочь системе. И интерфейсится к более мощным средствам, если надо. Как-то так я это и хочу видеть, прикиньте? Это логично и хорошо на мой взгляд.
> Вот как люди берутся столь беспардонно обобщать, вроде бы имея возможность оценить
> уровень своей некомпетентности и границы, соответственно, компетентности?Вот как люди берутся комментировать? Так что ни единого разумного, технически обоснованного аргумента. Только галимая субъективщина/вкусовщина да персональные атаки (и на поттера и на тех кто поддерживает его взгляды на то как надо рулить системами). Ну как бы удачи с таким подходом к делу. Вот только вранье и подтасовки в мире открытых исходников работать не будут, как и галимые персональные наезды.
>> Вы заслушали мнение админа локалхоста, который не сталкивался с тем, что давно
>> уж сделано и работает по части агрегирования логов.
> Спасиб, видели мы как это сделано.Перечислите названия инструментария, который вы "видили".
> Так что ни единого разумного, технически обоснованного аргумента.
Вот и посмотрим на ваши "технические аргументы".
> При том на половине систем этого никто никогда не увидит, пардон./var/log/messages уже лет 20 как существуют. Вы вообще книжки по UNIX`у то читали или только видео про systemd смотрите?
> /var/log/messages уже лет 20 как существуют.Осталось всего ничего: узнать кто это пишет, когда он становится доступен, почему в половине случаев там нифига полезного для заруливания проблемы нет и прочие "несущественные мелочи". Но с этим у крЮтых юниксоидов читавших книжки по жизни большие проблемы.
> Вы вообще книжки по UNIX`у то читали или только видео про systemd смотрите?
Я читал. И лично сходил и посмотрел как это сделано к тому же. И имею заметить что Поттер в отличие от скриптокидозных костылестроителей не стал забивать на ряд технически сложных, но вполне решаемых [более-менее компетентным системным программистом] проблем. Вот только я как-то совсем не испытываю желание окостыливать такие вещи лично, когда поттер это за меня сделает. Такой я нехороший :)
>> /var/log/messages уже лет 20 как существуют.
> Осталось всего ничего: узнать кто это пишет, когда он становится доступен, почему
> в половине случаев там нифига полезного для заруливания проблемы нетДатычо?! Там всё очевидно. Если нет, читай ман по своему сислогу, там всё очевидно.
>> Вы вообще книжки по UNIX`у то читали или только видео про systemd смотрите?
> Я читал. И лично сходил и посмотрел как это сделано к тому
> же.Что-то как-то сомневаюсь уже. Стесняюсь спросить какие ты книжки читал и туда смотрел.
> И имею заметить что Поттер в отличие от скриптокидозных костылестроителей
> не стал забивать на ряд технически сложных, но вполне решаемых [более-менее
> компетентным системным программистом] проблем. Вот только я как-то совсем не испытываю
> желание окостыливать такие вещи лично, когда поттер это за меня сделает.
> Такой я нехороший :)Поттеринг написал свою операционку, в которой в частности Инит умеет вэб-сервер, qr-код и ppp, но не умеет запускать сервис. Нравится — пользуйся.
> Поттеринг написал свою операционку, в которой в частности Инит умеет вэб-сервер,
> qr-код и ppp, но не умеет запускать сервис. Нравится — пользуйся.В рамочку, с Вашего позволения.
> /var/log/messages уже лет 20 как существуют. Вы вообще книжки по UNIX`у то читали или только видео про systemd смотрите?... и в котором в более-менее свежем дебиане можно найти чуть более, чем ничего, потому что все демоны пишут в daemon.log
> ... и в котором в более-менее свежем дебиане можно найти чуть более,
> чем ничего, потому что все демоны пишут в daemon.logСадись, два.
$ cat rsyslog.conf
...
-->8--
#
# Some "catch-all" log files.
#
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
-->8--
...Дебиан "самый свежий" - stable.
> Вы читать умеете ?Да.
> monit в такой ситуации будет вести себя совершенно также.
Нет.
>> monit в такой ситуации будет вести себя совершенно также.
> Нет.Аргументация из нелюбителей системды так и прет. Вынесет вас на свалку истории - туда и дорога, имхо. Правильно дебианщики сделали что послали таких граждан в пешее эротическое: снобье "а я привык вот так!" по другом один фиг не понимает.
> Что сервис лежит.Ну так там и было написано - failed. В каком месте слово failed может быть не понятно?
> User294, Вы же тут рвали всех за системдэшный
> мониторинг на британский флаг -- неужели сами при этом вообще
> никогда и ничего под таковой не загоняли?Пардон, как раз "мониторинг" тут сработал правильно, именно так как эта логика и задумана: попробовал запустить сервис, когда он помер (по каким-то внутренним причинам, неизвестным запускалке) - перезапустил. Но когда стало понятно что сервис нежизнепособен и случился лимит рестартов - на рестарты забили по лимиту рестартов. По факту это проблема на стыке интеграции в систему и кривой конфигурации, системд тут вообще вроде бы все сделал правильно, насколько позволяла ситуация.
Если что - априори системный стартер не знает от чего умер сервис. Поэтому логично что он попробует его перезапустить. Нескольких рестартов в такой ситуации при желании можно избежать. Что дебианщики и сделали, добавив sshd -t в prestart, так что если конфиг не пройдет проверку - теперь как я понимаю при барахле в конфигурации (а это и был реальный root cause обсуждаемой проблемы) - старт сервиса завалится сразу и совсем и рестартов не будет. Это уже из области шероховатостей интеграции.
Вопрос: при чем тут системд? Случилась лажа в конфигурации сервиса + интеграция с системд выполнена по первости весьма шероховато. Ну вот в том баге - показано как такое обработать напильником. Да, знаете, опыт "а как лучше сделать вот тут?" приходит не сразу. Дебианщики занимаются интеграцией системд в первый раз. Логично что некоторые шишки они набьют, пока научатся это делать хорошо и правильно.
# monit summary | grep sshd;
...
Оно как бы круто и замечательно. Но не используется system-wide и заглохло в развитии. Писать какой-нибудь там менеджер регистрации-дерегистрации VM и контейнеров самому мне как-то не упало, а вот видеть такую штуку я вполне хочу, на случай если захочется состыковать системы с энтерпрайзными управляторами и прочая.Поэтому по совокупности параметров я пожалуй буду предпочитать системд. За универсальное управление запуском. Мне не надо в системе 100500 запускалок в разных закоулках: админить такую систему и тем более передать ее кому-то на администрирование - сущий ад. И куча фич системды мне пригодится.
А monit - ну как бы не самая плохая на свете программа, но - не системная запускалка. И у него другие приоритеты. Ну вот скажем в systemd-only системе у меня нет вопроса "как мне запустить мой сервис всенепременно до программы X", например. И это большая победа. В апстарте так тоже можно, но зачастую неудобнее, ибо требует править job другому сервису, а это уже потенциальные грабли по линии пакетного менеджера. А вот у поттера в большинстве случаев можно обойтись только своим юнитом, поэтому такая проблема не стоит.
А зачем мне надо у..ще с названием sysv init - я не очень понимаю. Мне такая запускалка в системе вообще не нyжна. Я по этому гомнецу скучать не буду, даже и не надейтесь.
>> Что сервис лежит.
> Ну так там и было написано - failed. В каком месте слово failed может быть не понятно?В зелёном цвете, о болгарин. :)
> По факту это проблема на стыке интеграции в систему и кривой конфигурации,
> системд тут вообще вроде бы все сделал правильно, насколько позволяла ситуация.Нет -- криво выдал статус. А о том, что деятели, которые ногами писали инитскрипты, ещё хуже будут писать юниты -- уж давно предупреждал.
> Что дебианщики и сделали, добавив sshd -t в prestart
В альте, между прочим, многие сервисы как раз и проверяют пригодность конфига перед start/restart/reload. И уже много лет как.
> Дебианщики занимаются интеграцией системд в первый раз.
Это вопрос к тому, откуда взялся юнит-файл.
> Оно как бы круто и замечательно. Но не используется system-wide и заглохло
> в развитии.И опять врёте. Зачем? Так и скажите -- "в глаза не видел, мненинадо", будет по крайней мере честно.
> на случай если захочется состыковать системы с энтерпрайзными управляторами и прочая.
Хоть раз стыковали? Не ту винду, а линукс? Опять же не подковырка, а просто вопрос.
> Поэтому по совокупности параметров я пожалуй буду предпочитать системд.
Эт дело Ваше. Претензии -- к публичному вранью, которое ничем не лучше ваххабитского: такая же подмена понятий и впаривание как минимум непроверенных сведений и идей.
> Ну вот скажем в systemd-only системе у меня нет вопроса "как мне
> запустить мой сервис всенепременно до программы X", например.http://mmonit.com/monit/documentation/monit.html#SERVICE-DEP...
> даже и не надейтесь.
Я Вам инитом не прихожусь, с эмоциями уж как-то сами разбирайтесь :)
> А о том, что деятели, которые
> ногами писали инитскрипты, ещё хуже будут писать юниты -- уж давно
> предупреждал.Мда. Но у меня тут культурный шок из-за Colin'а. Он типа ТС, хоть и бывший.
>> Что дебианщики и сделали, добавив sshd -t в prestart
> В альте, между прочим, многие сервисы как раз и проверяют пригодность конфига
> перед start/restart/reload. И уже много лет как.Так было и в debian, т.е. это регрессия. Правда, похоже что проблема куда
глубже и "добавка" решает лишь часть...>> Дебианщики занимаются интеграцией системд в первый раз.
> Это вопрос к тому, откуда взялся юнит-файл.Ну откуда. Оттуда же, откуда и socket-активация...
> Так было и в debian, т.е. это регрессия.Понимаю и соболезную :-(
> В зелёном цвете, о болгарин. :)Там написано про какой-то зеленый кружок вроде. Да, ужасный баг. А когда в дебиане nginx не сносился, потому что скрипт его остановить не мог - это ничего так было, да?
> ногами писали инитскрипты, ещё хуже будут писать юниты -- уж
> давно предупреждал.Вот когда они попишут юниты столько же сколько они писали скрипты - тогда и будет логично сравнивать результаты. Ну так, чтобы сравнение в одинаковых условиях было. Но мне кажется что будет сильно лучше. Мест для лажи меньше. Да и исправлять лажу в трех строках конфига проще чем в черти-каких огроменных простынях.
> В альте, между прочим, многие сервисы как раз и проверяют пригодность конфига
> перед start/restart/reload. И уже много лет как.В альте наворотили целую коллекцию либ на шеллскриптах. Тотально несовместимо с другими дистрами, btw. В результате - знания о всех этих наворотах оказываются наглухо бесполезны за пределами мелкого, местечкового и нишевого альта. Я конечно понимаю что для каждого програмера своя программа самая лучшая. Но для остальных - это довольно большой объем относительно малополезных знаний. Что совсем не добавляет желания впихивать все это в свою голову. У поттера же знания о его конструкции - пригодятся и в редхате, и в федоре, и в дебиане, и в убунте. Да и вообще - там все как-то просто и логично сделано, процентов на 70-80 оно ведет себя как-то так как я себе это и представлял.
>> Дебианщики занимаются интеграцией системд в первый раз.
> Это вопрос к тому, откуда взялся юнит-файл.В любом случае, майнтайнеры в ответе за свой пакет. И за дефолтную конфигурацию, и за старт-стоп. При том в дебиане старт/стоп порой так весело сделан что вообще не поймешь "блин, откуда ж этот чертов openvpn взлетел, если я его в стартере наглухо вырубил?! Ах, еще при передерге сетевого и-фейса скрипт отдельно его стартует, поклав на disable?!".
Теперь есть надежда что такой пи...ц пойдет на убыль. Постепенно скриптописаки научатся отрабатывать старт/стоп только через системд. И ни одна сволочь больше не будет сметь запускать сервис откуда-то сбоку-припеку, поклав на то что я скомандовал disable этому сервису в стартере. И это - так как оно должно было быть с самого начала.
> И опять врёте. Зачем? Так и скажите -- "в глаза
> не видел, мненинадо", будет по крайней мере честно.Это не будет честно - когда-то видел. Но сейчас могу и не вспомнить деталей - просто потому что не понял в чем пойнт этой штуки. Мониторинг там конечно более развит, системд до этого далеко. Но вот как системный стартер я себе это с трудом представляю (вроде какие-то дистры пытались?). А мониторинг портов - это круто. Только если скажем через 2 хопа роутер упал - оно будет считать что все оки-доки. И админа не заалертит (а если б и пыталось то скорее всего не смогло). Так что при желании мониторить доступность сервисов - это уже в общем случае заявка на совсем другую систему мониторинга. По поводу чего я допускаю что monit имеет право на существование. Но почему он так уж нужен мне - я для себя так и не придумал. И уж тем более мне не требуется sysv init.
> Хоть раз стыковали? Не ту винду, а линукс? Опять же не подковырка, а просто вопрос.
Я имел дело с разными средствами группового администрирования. С разными ОС. Поэтому я представляю себе как это выглядит. И в курсе как это работает. Но в именно том формате который хочет сделать поттер - разумеется нет, т.к. это еще в зачаточном состоянии.
Поттер судя по всему хочет сделать некий стандартный и-фейс для управлятора. Менеджер системы - на самом правильном месте для этого, и название хорошо отражает суть затеи. Менеджер регистраций, отгрузка логов, etc - все идет к тому чему и должно. И имхо лучше пусть поттер у себя баги 1 раз починит чем я буду лицезреть баги и глюки кастомных ремотных агентов, кучи самопального glue code писаного на коленке и прочая.
> Эт дело Ваше. Претензии -- к публичному вранью, которое ничем не
> лучше ваххабитского: такая же подмена понятий и впаривание как минимум
> непроверенных сведений и идей.Если честно - я ничего не имею против monit. А вранье скорее всего обусловлено склерозом: я вертел его в руках довольно давно и так и не понял какие мои юзкейсы им было бы логично разруливать.
>> Ну вот скажем в systemd-only системе у меня нет вопроса "как мне
>> запустить мой сервис всенепременно до программы X", например.
> http://mmonit.com/monit/documentation/monit.html#SERVICE-DEP...Ну понятно. Т.е. в принципе есть. Но насколько я понимаю - не совсем так как я хочу.
Смотрите, достаточно типичный для меня юзкейс: есть сервис которого не было в пакетах. Я его собрал сам. Хочется запускать его скажем всенепременно ДО некоторого иного сервиса. Ну может он конфиг генерит этому сервису на ходу. Или что-то еще делает, затрагивающее тот другой сервис, по поводу чего взлет моего сервиса - должен быть строго ДО, и никак иначе.
Теперь, допустим что тот второй сервис - часть системы, в том смысле что он корректно установлен пакетным менеджером и прочая. По поводу чего кроме всего прочего - стартеру прописан запуск общепринятыми в системе методами, а стартовый конфиг принес пакет при установке. Мое пожелание к стартеру: возможность не трогать файлы того второго сервиса касающиеся старта, чтобы не узнавать как именно майнтайнер того пакета обрабатывает стартовые файлы и прочий крап. Я хочу подпихнуть в систему свой сервис и чтобы все и вся определялось ТОЛЬКО ЕГО конфигом. Трогать стартовые файлы других файлов МНЕ СОВЕРШЕННО НЕ ХОЧЕТСЯ.
В monit как я понимаю надо будет дописать тому второму сервису depends в его стартовый конфиг. При этом, если конфиг для старта принес пакетный менеджер - я залетаю на узнавание того не перетрет ли пакетный манагер этот стартовый конфиг, надо ли diversion делать и прочая. Костыли, короче.
А у поттера можно просто написать Before= в юните моего сервиса. И не надо трогать другие конфиги. И греть мозг вопросами кто и когда (пакетный манагер при обновлении, etc) их у того второго сервиса может перетереть. Мне так кажется здорово удобнее и менее проблемно в плане взаимодействия с пакетным менеджером. В апстарте кстати подобные грабли порой заставляют икать - сделать правильный boot ordering без правки конфигов других сервисов может и не выйти. А узнавать как именно тот майнтайнер обрабатывает стартовые конфиги - а оно мне надо? Вот системд как-то обеспечивает отсуствие таких дурных заморочек на ровном месте при интеграции моего нового кастомного сервиса в систему. В том плане что никто не перетрет ВНЕЗАПНО конфиг, так что через месяц все неожиданно отвалится, потому что майнтайнер пакета решил стартовые конфиги обрабатывать вот так а не эдак и поэтому вынес все мои изменения.
> А когда в дебиане nginx не сносился, потому что скрипт его остановить не
> мог - это ничего так было, да?Этот баг был в релизе? Ах, не был.
А этот - видимо будет. И я еще по одному sshd могу пройтись собрать такие
"результаты" systemd коричневого оттенка...>> ногами писали инитскрипты, ещё хуже будут писать юниты -- уж
>> давно предупреждал.
> Вот когда они попишут юниты столько же сколько они писали скрипты -
> тогда и будет логично сравнивать результаты. Ну так, чтобы сравнение в
> одинаковых условиях было. Но мне кажется что будет сильно лучше. Мест
> для лажи меньше.Когда они не могут просто портировать работающий init-скрипт без
регрессий - о чем можно говорить? И это не школьник-вася, мейнтейнер
пуперd - это openssh!>> В альте, между прочим, многие сервисы как раз и проверяют пригодность конфига
>> перед start/restart/reload. И уже много лет как.
> В альте наворотили целую коллекцию либ на шеллскриптах. Тотально несовместимо с другими
> дистрами, btw.А результат использования этих либ - совместим? Надеюсь, что на том уровне
что стандартизован LSB - да. Нет причин и ожидать большего.>>> Дебианщики занимаются интеграцией системд в первый раз.
>> Это вопрос к тому, откуда взялся юнит-файл.
> В любом случае, майнтайнеры в ответе за свой пакет. И за дефолтную
> конфигурацию, и за старт-стоп. При том в дебиане старт/стоп порой так
> весело сделан что вообще не поймешь "блин, откуда ж этот чертов
> openvpn взлетел, если я его в стартере наглухо вырубил?!Видимо, так "вырубил". Пойми, пожалуйста. Документацию читать надо
не только в systemd. Даже если ты считаешь себя самым умным.> поклав на то что я
> скомандовал disable этому сервису в стартере.Ты просто неправильно отключил сервис. Делается это в /etc/defaults, все
было замечательно стандартизовано. Просто ты не потрудился
разобраться на элементарном уровне.Кстати, при использовании systemd - ничего и не поменяли в
openvpn.if-up.d (systemctl start вызывают вместо /etc/init.d/openvpn start).>> И опять врёте. Зачем? Так и скажите -- "в глаза
>> не видел, мненинадо", будет по крайней мере честно.
> Это не будет честно - когда-то видел. Но сейчас могу и не
> вспомнить деталей - просто потому что не понял в чем пойнт
> этой штуки. Мониторинг там конечно более развит, системд до этого далеко.Пойнт в том, что monit - это мониторинг.
То что есть от подобного функционала в systemd - огрызок, который еще
и мешаться будет нормальному мониторингу. Ну захотят systemd и monit
одновременно перезапустить сервис... Или захочет systemd, а в процессе
захочет monit... Ой, беда ж.> Но вот как системный стартер я себе это с трудом представляю
> (вроде какие-то дистры пытались?). А мониторинг портов - это круто. Только
> если скажем через 2 хопа роутер упал - оно будет считать
> что все оки-доки. И админа не заалертит (а если б и
> пыталось то скорее всего не смогло).Оно не смогло б, или просто ты - не смогло?
Фишка monit (проактивный мониторинг, епт), впрочем, не в "алертах" для последующих
аччотов, а в том что он будет пытаться самостоятельно исправить проблему по-возможности. Перезапустит сервис, поправит приоритеты, запустит скрипты для диагностики и устранения проблемы...>> Хоть раз стыковали? Не ту винду, а линукс? Опять же не подковырка, а просто вопрос.
> Я имел дело с разными средствами группового администрирования. С разными ОС.Да уж, уши винадмина - не скроешь.
> А у поттера можно просто написать Before= в юните моего сервиса. И
> не надо трогать другие конфиги.Это не самая мудрая вещь, мягко говоря. Зависимости должен указывать, пардон,
тот кто зависит. А ты предлагаешь - наоборот.Не удивительно, что эдакую дурь ни в apt-get/yum ни впихнули, ни в стандарт LSB для
init-скриптов, ни в monit.
> Что дебианщики и сделали, добавив sshd
> -t в prestart, так что если конфиг не пройдет проверку -
> теперь как я понимаю при барахле в конфигурации (а это и
> был реальный root cause обсуждаемой проблемы) - старт сервиса завалится сразу
> и совсем и рестартов не будет.У меня лично возник вопрос, почему элементарный функционал, который был
в старом init-скрипте - никто не почесался перенести в unit-файл. Учитывая то,
что в числе мейнтейнеров даже члены TC - можно только за голову схватиться...> Это уже из области шероховатостей интеграции.
За такую "шороховатость" - нужно кастрировать.
>
# monit summary | grep sshd;
> ...
>
> Оно как бы круто и замечательно.Оно не просто "круто" - оно сделано правильно. А не огрызок в виде
решения десятой части задач мониторинга.Мониторинг должен уметь все необходимое - либо не путаться под ногами
вовсе, притворяясь мониторингом.> Но не используется system-wide и заглохло в развитии.
Пока systemd не начали активно впихивать в debian (т.е. сделали
умолчанием) - число пользователей у monit по popcon было сопоставимым. Можешь
сам проверить - статистика доступна на страничках пакетов.> А monit - ну как бы не самая плохая на свете программа,
> но - не системная запускалка. И у него другие приоритеты.Да, это проактивный мониторинг. Do one thing and do it well.
> А зачем мне надо у..ще с названием sysv init - я не
> очень понимаю. Мне такая запускалка в системе вообще не нyжна.Тебе, дураку, нет. А людям - нужна, чтобы идиотские баги вида цитированного
на голову не валились.
> в старом init-скрипте - никто не почесался перенести в unit-файл.Ну поди да спроси у майнтайнера почему он сделал так или этак. Или ты хочешь чтобы я тебе вместо майнтайнера на картишках раскинул? Ну что за литтл ламо!
> что в числе мейнтейнеров даже члены TC - можно только за голову схватиться...
У тебя голова все-равно пустая, так что без разницы.
> За такую "шороховатость" - нужно кастрировать.
Флаг тебе в руки. Замечу что фикс - одна строка. Аж.
> Оно не просто "круто" - оно сделано правильно.
А фиг там. См. про зависимости в #66. Там я расписал почему поттер с юнитами все сделал правильно - мне не придется diversion в пакетном манагере лишний раз фигачить и вообще греть мозг вопросом кто может перетереть файлы которые были до меня.
> А не огрызок в виде решения десятой части задач мониторинга.
Если уж на то пошло - а еще может роутер упасть через 2 хопа. В том же ДЦ, но - другая железка. Ну и фули будет толку с monit? Он даже алерт админу пульнуть не сможет :). Поэтому если уж надо реально крутой мониторинг - это делаеся иначе. А монит - ни два ни полтора. Ну да, мониторинг у него пофичастее. Но в целом я слабо представляю юзкейсы где он бы хорошо для меня вписался и стал единственной запускалкой в системе. Как я уже сказал - месиво из пяти разных запускалок в системе мне совершенно ни к чему.
> Мониторинг должен уметь все необходимое - либо не путаться под ногами
> вовсе, притворяясь мониторингом.Ну а вот monit не сможет ничего сделать по поводу того что роутер через 2 хопа от текущей машины околел и перестала быть дотупна сеть на машинах за ним. Так что, monit должен перестать путаться под ногами, да? :)
> Пока systemd не начали активно впихивать в debian (т.е. сделали
> умолчанием) - число пользователей у monit по popcon было сопоставимым. Можешь
> сам проверить - статистика доступна на страничках пакетов.Если уж на то пошло - дебианщики могли бы и monit сделать дефолтным стартером. У низ был выбор. Но как видим - он оказался в пользу системд.
> Да, это проактивный мониторинг. Do one thing and do it well.
Прекрасно, только мне в системе нафиг не упало два разных стартера. Да и более навороченные системы мониторинга - мониторят доступность лучше. В том плане что мониторинг доступности сервиса с нескольких точек в сети - намного лучше отвечает на вопрос "доступен ли сервис?". Но такие запросы уже несколько не про monit - его штатное применение такие навороты не предусматривает.
> Тебе, дураку, нет. А людям - нужна, чтобы идиотские баги вида
> цитированного на голову не валились.А там таких багов - 100500 штук. Только заныканых по скриптам а не юнитам. Единственное отличие. И да, у дебияна в древней версии даже нжинкс не сносился корректно, потому что скрипт остановки нжинкса лажал. Так что чья бы уж мычала...
>> в старом init-скрипте - никто не почесался перенести в unit-файл.
> Ну поди да спроси у майнтайнера почему он сделал так или этак.Потому что даже мейнтенеры одного из важнейших пакетов - не разобрались
с вашей дурью нормально. Как это будет выглядеть для остальных пакетов?>> За такую "шороховатость" - нужно кастрировать.
> Флаг тебе в руки. Замечу что фикс - одна строка. Аж.Расскажи это мейнтейнерам - они почему-то не вкурсе.
>> Оно не просто "круто" - оно сделано правильно.
> А фиг там. См. про зависимости в #66. Там я расписал почему
> поттер с юнитами все сделал правильноОн сделал там такую дурь, что никто до него в здравом уме
не делал. #69Зависимости должен указывать тот, кто зависит.
>> А не огрызок в виде решения десятой части задач мониторинга.
> Если уж на то пошло - а еще может роутер упасть через
> 2 хопа. В том же ДЦ, но - другая железка. Ну
> и фули будет толку с monit? Он даже алерт админу пульнуть не сможет :).Ты - не сможешь, а monit - сможет.
> Поэтому если уж надо реально крутой мониторинг -
> это делаеся иначе.Фишка monit - в том, что это проактивный мониторинг. Он не просто рапортует
тебе о проблемах, он пытается их решить.Немножко другие приоритеты чем у систем типа zabbix'а (хотя там
тоже вроде что-то аналогичное прикрутили).> Но в целом я слабо представляю
> юзкейсы где он бы хорошо для меня вписался и стал единственной
> запускалкой в системе. Как я уже сказал - месиво из пяти
> разных запускалок в системе мне совершенно ни к чему.Прочитай, наконец, man init и пойми что monit можно сделать
единственной запускалкой, вместо /etc/init.d/rc. В документации
monit'а тоже подробно объяснено как, для самых тупых.>> Мониторинг должен уметь все необходимое - либо не путаться под ногами
>> вовсе, притворяясь мониторингом.
> Ну а вот monit не сможет ничего сделать по поводу того что
> роутер через 2 хопа от текущей машины околел и перестала быть
> дотупна сеть на машинах за ним.А что он должен сделать? Послать смс админу. Неужели systemd способен на
большее? Сильно сомневаюсь.>> Пока systemd не начали активно впихивать в debian (т.е. сделали
>> умолчанием) - число пользователей у monit по popcon было сопоставимым. Можешь
>> сам проверить - статистика доступна на страничках пакетов.
> Если уж на то пошло - дебианщики могли бы и monit сделать
> дефолтным стартером. У низ был выбор. Но как видим - он оказался в пользу системд.Не один человек уже писал о том, что выбор уж больно был похож
на выбор крылатой демократии...Цена ему... Вменяемые люди - разбегутся, а гопников типа ИГИЛ - наберется
со временем все больше...>> Да, это проактивный мониторинг. Do one thing and do it well.
> Прекрасно, только мне в системе нафиг не упало два разных стартера.Сделай один.
> Да и более навороченные системы мониторинга - мониторят доступность лучше.
Дубина. Monit - не для мониторинга доступности. Есть понятие - проактивный
мониторинг. Пожалуйста, ну прочитай словари прежде чем ***у с пальцем сравнивать
в следующий раз.>> Тебе, дураку, нет. А людям - нужна, чтобы идиотские баги вида
>> цитированного на голову не валились.
> А там таких багов - 100500 штук. Только заныканых по скриптам а не юнитам.Приведи ровно один для начала.
> И да, у дебияна в древней версии
> даже нжинкс не сносился корректно, потому что скрипт остановки нжинкса лажал.Не было такой версии "дебияна", не ври. Подобная проблема была в каком-то
тестинге - и теперь опеннетовские тролли, вроди тебя, тыкают ей при любом
удобном случае. Потому что на большее чем попугайство - не способны.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913 - не RC баг.Так вроде пишут что починили. Врут?
Починили в классическом стиле Леннарта: "Рафик ниучем ниуиноуат. Оказалось sshd какой-то неправильный."
То что сервисы забывают запуститься, особенно сетевые, это еще джва года назад видел на Федоре. Лечил костылями в юнитах.
Ну а починку дepьмища за кульсисопами в соплях на инитовских скриптах мы как обычно забудем. Ведь "Рафик ниучем ниуиноуат", да? Вот это я и понимаю - специалист по разведению двойных стандартов :)
> Ну а починку дepьмища за кульсисопами в соплях на инитовских скриптах мы
> как обычно забудем. Ведь "Рафик ниучем ниуиноуат", да? Вот это я
> и понимаю - специалист по разведению двойных стандартов :)От специалиста по подмене понятий и слышу.
Даже если мэйнтейнер напишет нечто эдакое ((RANDOM%2==0)) && /usr/sbin/httpd, чтобы эмулировать функциональность systemd, не вижу в чем здесь виноваты авторы PID 1.
> функциональность systemd, не вижу в чем здесь виноваты авторы PID 1.Они виноваты только в том что умыли руки от всех проблем, спихнув все и вся на админа. Хорошо что поттер не такой лузер и трус.
> Они виноваты только в том что умыли руки от всех проблем,
> спихнув все и вся на админа.Не "умыли руки", а "дали инструмент". Если админ настолько инфантилен, что неспособен ни сделать свою работу, ни выбрать дистрибутив, где она в общем виде уже сделана хорошо -- таки вон из профессии.
> Хорошо что поттер не такой лузер и трус.
Ага, потому и тормозов этот официально-не-админ не придумывает, и отвечать ни перед кем не собирается. В отличие от админа, из зарплаты которого часть за ответственность никуда не девается.
Скажите, сколько серверо-лет у Вас уже наработал systemd, и будет видна цена этим тирадам.
> Не "умыли руки", а "дали инструмент".Если по такой же логике производить компьютеры - вместо компьютера вам надо дать кирку. Накопаете медной руды - тогда поговорим, дескать. О том как ее выплавить. А потом - о том как раскатать в тонкие листы. А потом изучим как печатную плату из этого делать. Попутно узнав как производить стекловолокно и чем его пропитывать. И где все это берется.
> неспособен ни сделать свою работу, ни выбрать дистрибутив, где она в
> общем виде уже сделана хорошо -- таки вон из профессии.Ну вот мы и посмотрим кто теперь будет вон из профессии. А я тоже человек и решать давно решенные задачи в 100500-й раз меня не прет. И тот ужастик который в альте нагородили тоже оптимизма не вызывает. В #66 подробно рассказано почему.
> отвечать ни перед кем не собирается.
Так он вроде и не подписывался перед вами отчитываться. Я думаю что вам свое ЧСВ пора бы иногда строить уже. И вообще - поменьше зарываться и побольше думать головой: кто, кому, чего и почему должен.
> В отличие от админа, из зарплаты которого часть за ответственность никуда не девается.
Со своей стороны - я лучше буду отвечать за то что наделал поттер чем за то адовое месиво которое обычно устраивают в скриптах.
> Скажите, сколько серверо-лет у Вас уже наработал systemd, и будет видна цена этим тирадам.
Интересный формат "спервадобейся". Но если в него утыкаться - прогресс умрет.
А так - ну вон RHEL7 вышел не вчера. Но массовых воплей о том как все плохо - нет. А громче всех орут те кто системд вообще не пользуются. Нафига мне их мнение учитывать - я вообще не понимаю. Ну не пользуются - и славненько. А я вот буду пользоваться. И не вижу оснований для того чтобы он был таким уж ненадежным. Да и то что было ДО него в виде кучи скриптовых сопель писаных абы как - никакой меганадежностью не отличалось. Т.е. как минимум хуже в общем случае не станет.
И вот что-что, а в вопросах качества софта я возымею наглость верить себе. Потому что человеко-лет в соответствующей области мной отработано явно больше.
> А так - ну вон RHEL7 вышел не вчера. Но массовых воплей
> о том как все плохо - нет.Для начала, а им пользуются? Я еще во времена пятерки и шестерки сталкивался с тем,
что народ на них вроде как даже и не переходил. Не говоря уже о том,
чтобы делать это активно...
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913 - не RC баг.
> Так вроде пишут что починили. Врут?Починили - это когда "Done", а релиз раскрашен зелененьким...
> Починили - это когда "Done", а релиз раскрашен зелененьким...Ну я как минимум вижу там fix в плане правки юнита systemd для более логичного поведения, с проверкой конфига в prestart. Как там бюрократия будет вертеться по этому поводу дальше - на совести бюрократов.
Ура!
Типа назло Ubuntu 15.04?
С первым апреля всех поздравили разработчики Debian.
> С первым апреля всех поздравили разработчики Debian.В столице к посольству Debian-а граждане несут венки. Гарант телеграфировал соболезнования.
Ядро 3.16 ?
Блин, а на kernel.org его уже давно нет :(
> Ядро 3.16 ?
> Блин, а на kernel.org его уже давно нет :(Это та версия, которая встроена в systemd на ubuntu.com. Надо же следить за новостями!
http://www.opennet.me/openforum/vsluhforumID3/101141.html#59
Странно, пытаюсь нагуглить, ничего такого не находит про systemd...
Правда, Гугл работает немного странно, у меня у одного все наоборот? https://com.google/
> Странно, пытаюсь нагуглить, ничего такого не находит про systemd...
> Правда, Гугл работает немного странно, у меня у одного все наоборот? https://com.google/Это для людей, которые пишут овелан аварпс, заставляют женщин скрывать лица под чалмой, и люто, бешено ненавидят демократию по-американски. Особенно, когда она внезапно падает на голову в виде ракет и бомб.
> под чалмой, и люто, бешено ненавидят демократию по-американски. Особенно, когда она
> внезапно падает на голову в виде ракет и бомб.Какой примитивный тролленок попался :)
>Это та версия, которая встроена в systemd на ubuntu.comА здесь пишут про другое: https://www.linux.org.ru/news/android/11464878
Кому верить?
где-то слышал, что дальше убунтари и дебианщики его будут совместно тянуть.
хотя: аж целый месяц назад обновлялось в Jessie. оно же в Ubuntu Utopic с тех пор обновилось 2 раза
Ясно. Как-то не очень позитивно, ну да ладно.
быстровато что-то для Дебиана... это не первоапрельская шутка?
а вообще жду. в смысле, не столько выпуска Jessie жду, сколько разморозки Testing
> быстровато что-то для Дебиана... это не первоапрельская шутка?Так они же не сказали в каком году, так что нормальненько :)
да нет, сказали:
> Jessie Release Date: 2015-04-25https://lists.debian.org/debian-devel-announce/2015/03/msg00...
И новость не от 1 апреля, а от 31 марта, так что, может, и не шутят
А wxgtk по-прежнему падает !!
firmware-b43-installer - зло! Я с ним тож намучался в последнем гентушном ядре(((( Пришлось старое из бэкапа разворачивать. Беда-печаль(((
Время 14:50, а релиза еще нет. Ожидание - пытка!
Отменили что-ли?
УРА! Вышел! Вышел!
> УРА! Вышел! Вышел!Что ты, дурак, радуешься?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913
- как висел, так и висит.
Я ssh.service не использую.