Разработчики проекта Debian назначили (https://lists.debian.org/debian-devel-announce/2017/05/msg00...) дату релиза Debian 9.0 "Stretch". Релиз планируется выпустить 17 июня, в связи с чем запущена инициатива по проведению в этот день мероприятий (https://wiki.debian.org/ReleasePartyStretch), приуроченных к выходу Debian 9.0. В странах бывшего СССР мероприятий пока не назначено.В настоящее время насчитывается (http://bugs.debian.org/release-critical/) 120 критических для формирования релиза ошибок. До 6 июня планируется закрыть все эти ошибки. Проблемы которые не удастся устранить до этого дня будут помечены флагами stretch-ignore или stretch-will-remove. За неделю до намеченного релиза (9 июня) все пакеты, помеченные флагом stretch-will-remove, будут удалены из репозитория, если в ветке Testing для них не будут предложены исправления критических проблем. Начиная с 9 июня ветка Testing будет полностью заморожена от внесения изменений (исключение делается только для экстренных вмешательств)
URL: https://lists.debian.org/debian-devel-announce/2017/05/msg00...
Новость: https://www.opennet.ru/opennews/art.shtml?num=46606
Праздник！Вкатываю его сейчас на пролиант. Как раз к релизу заработает на боевом месте.
> Праздник！Через 3 месяца релизнется CentOS 7.4 - будет настоящий праздник. Network Bound Disk Encryption, RAID Takeover и много-много обновлений и нового полезного функционала.
В то время когда дебианщики готовы половину обновлений выкинуть лишь бы как-нибудь слатать релиз.
После выхода свежей версии CentOS тяну месяц-другой с обновлением,и всё равно непременно что-нибудь отваливается. Debian обновляю, не дожидаясь релиза, через некоторое время после заморозки, и как правило всё работает. Такая вот обратная (а кому и лицевая) сторона медали.
Так было до 8-ки с систымдым. Это был первый за всю жизнь демьян который сам не перешел, ваааще анатендед, на новую версию. Пришлось засучить и белыми ручентками :-(
Будем посмотреть что выйдет с 9-кой. Надеюсь вылижут как это было в преждние ...
> Так было до 8-ки с систымдым. Это был первый за всю жизнь
> демьян который сам не перешел, ваааще анатендед, на новую версию.Никакого "анатендед" и "ваще сам" у них никогда не было.
У вас - могабыть, а у них -- отдельная глава про Upgrading в ... то ли R.N., то ли в U.M., навскидку не помню сейчас. С пошаговыми "делай раз", "делай два" и приглащениями писать письма-баги, ежели что не так. И бэкапами -- обязательно в рекомендациях == "мы в домике".
//Disclosure: Здесь wheezy 7.11 + LTS. Уверен, что в 8+ это не поменялось.
>Через 3 месяца релизнется CentOS 7.4... и перечислил фичи ядра :-)
Ну я возьму из бэк-портов такую же версию - и у меня все эти фишки будут :-р
> Вкатываю его сейчас на пролиантУдачи
https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug...
> failed to boot in HP Proliant DL380 G5, but previous kernel does boot
>> Вкатываю его сейчас на пролиант
> Удачи
> https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug...
>> failed to boot in HP Proliant DL380 G5, but previous kernel does boot
>Всё как по маслу. У меня ген9 580.
Не расстраивайся! Бедность - не порок! (С) Теллер в одном швейцарском банке :)
на моём основном компьютере - ниработаит. так что или обновлю всё, кроме ядра (останусь на 3.16), или буду искать другое ядро.сначала не работало, пока не заблеклистишь звук, а теперь не работает видео, если не уберёшь kms, и тогда можно только сидеть в консоли 80x25
Основной - Пентиум?
Может пришло время что то менять?
такой, какой мне более удобен, тот и основнойработает, меня устраивает. а вот новое ядро почему-то не устраивает. значит, основной ОС там будет не Debian, а OpenBSD. а Debian 8, который будет ещё поддерживаться в рамках LTS, будет на случай, когда понадобится kvm/virtualbox или флеш-видео
man reportbug
> на моём основном компьютере - ниработаит. так что или обновлю всё, кроме
> ядра (останусь на 3.16), или буду искать другое ядро.(aptosid или liquorix в помощь)
Пока не понял в чём проблема, но в новой версии systemd перестало работать оповещение о старте процесса через systemd-notify --ready (ну и пробовал READY=1 через socat в bash, и вариант через python).У процесса Type=notify, NotifyAccess=all. Переменную окружения с путём к сокету проверял, передаёся. Но из дочернего процесса сообщение через сокет не приходит, похоже. При этом в списке дочерних процессов по команде статуса дочерний процесс значится. Сервис завершается по таймауту. При этом сама команда systemd-notify --ready успешно завершается, что очень удивляет. Но если запустить службу заново, то всё работает.
В прошлой версии Debian не работало в случае, если дочерний процесс был запущен из-под другого пользователя. Видимо придётся отлаживать systemd, правда пока даже с чего начать не знаю.
Переходи на Devuan - там нет этих проблем.
Вообще, достаточно бессмысленные советы. Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода. Как минимум мне самому пришлось бы реализовывать межпроцессное взаимодействие для распараллеленной загрузки моих служб по событийной модели. Мне и так хватает этого в коде на Си. И если с парой-тройках служб это ещё можно сделать без автоматизации, то с 10-ю мне пришлось бы уже сильно поднапрячься и реализовывать свою систему загрузки с зависимостями. Ну и зачем мне это, если такую систему уже изобрели до меня? Меньше времени уж тогда займёт, разобраться с исходниками, сделать и отправить патч, если там есть ошибка. Я понимаю, что это деление на за и против - вроде субкультур, но тут дела программистов. Если для обычного человека при переходе на двухядерный процессор с меньшей частотой всё просто стало работать медленнее, то программист знает, что на тот момент разработчики ПО просто не заморачивались на многопоточность. Это просто аналогия, но, думаю, вы поняли идею.
> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода.
> (ну и пробовал READY=1 через socat в bash, и вариант через python).socat-то конечно "проще", чем netstat -nxp | grep ...
> И если с парой-тройках служб это ещё
> можно сделать без автоматизации, то с 10-ю мне пришлось бы уже
> сильно поднапрячься и реализовывать свою систему загрузки с зависимостями.LSB-заголовки в run-скриптах init.d обеспечивают загрузку по зависимостям.
Система зависимостей предполагает оповещение о том, что процесс проинициализировался (например, сервер проинициализировал сокет к нему можно подключаться), а не просто запустился. Не успел столкнуться в с этим в SysV, но может расскажете, как там процесс оповещает о том, что он готов? У systemd описание unit-файлов в этом плане достаточно простым и понятным оказалось. Есть, конечно много спорных моментов, но в целом пригодно к использованию.
> Система зависимостей предполагает оповещение о том, что процесс проинициализировался
> (например, сервер проинициализировал сокет к нему можно подключаться), а не просто
> запустился. Не успел столкнуться в с этим в SysV, но может
> расскажете, как там процесс оповещает о том, что он готов? У
> systemd описание unit-файлов в этом плане достаточно простым и понятным оказалось.
> Есть, конечно много спорных моментов, но в целом пригодно к использованию.Если есть зависимость от сокета, решается вбиванием перед запуском костыля типа
while ! [ -S "$SOCKET" ]; do sleep 1; done
Но на самом деле ситуация довольно редкая. Большинство демонов пытаются подключиться к сокету не сразу при запуске, а только когда возникает необходимость, и если им это не удалось — спокойно переподключаются позднее. Если там наколенная поделка — лучше её допилить, чтобы она вела себя именно так, даже при использовании systemd.
Большая часть межпроцессного взаимодействия в Линуксе построена на сокетах (unix-). Если есть зависимость, значит она вероятнее всего будет связана с запуском сервера. Костыли со sleep - это бред. Допускаются только блокирующиеся операции. Полагаю, что большая часть ПО в дистрибутиве будет использовать сокеты. Самый простой пример - Иксы. Другой пример - d-bus. И как думаете, что будет, если сначала стартануть Иксы, а затем openbox? openbox попытается подключиться к иксам, которые ещё не успели начать прослушивать unix-сокет. Конечно, в дистрибутивах так не делают (openbox скорее всего будет просто дочерним процессом для иксов), это вполне допустимая ситуация.
И как же, по-Вашему, все жили без systemd?
Недоступность сокета — это рядовая ситуация, а не фатальная ошибка, особенно если учесть, что сокет может быть не только локальным, но и сетевым. Все демоны (именно демоны, запускаемых руками клиентских приложений это не касается) должны уметь обрабатывать такую ситуацию.
Может приведёте хотя бы один пример? Я по опыту не помню подобных ситуаций. Обычно просто делается завершение работы и всё.
Приведите пример того, что завершается.
openbox, x11vnc, zenity и скорее всего любое графическое приложение, если сокет иксов не создан. Это из того, с чем сталкивался на своём опыте.Другой пример, посерьёзнее. Что будет, если прокси-сервер nginx стартанёт после сервера bind9, в котором локальная доменная зона, указанная в конфигурации nginx?
Ну и попробуйте запустить какой-нибудь сервис, работающий через dbus, а только потом запустите сам dbus. Тут проверять необходимо, т.к. можно было реализовать через inotify с мониторингом каталога, в котором сокет должен находиться. Но это не портабельно.
> openbox, x11vnc, zenity и скорее всего любое графическое приложение, если сокет иксов не созданА что системде уже и их сам запускает? Вообще это совершенно не дело системы инициализации. Я, повторюсь, писал про
>> именно демоны, запускаемых руками клиентских приложений это не касается
> Что будет, если прокси-сервер nginx стартанёт после сервера bind9, в котором локальная доменная зона, указанная в конфигурации nginx?Думаю, выдаст на пришедший в этот момент запрос 502, после поднятия бинда заработает нормально. Разве не так?
> попробуйте запустить какой-нибудь сервис, работающий через dbus, а только потом запустите сам dbus
Много ли системных сервисов используют dbus, кроме системде? Я ни одного не припоминаю, так что сделать этого, увы, не смогу.
> Думаю, выдаст на пришедший в этот момент запрос 502, после поднятия бинда заработает нормально. Разве не так?Ну, вы так думаете из-за того, что не знаете, как работает ДНС и как делается обработка ошибок в ПО (lazy). nginx в Debian 7 делает запрос ip-адреса, чтобы начать прослушивание. Но т.к. адреса нет просто завершается по ошибке. И сюрприз, сайт лежит. Но достаточно его стартануть опять, как он снова работает. И не каждый сисадмин догадается в чём дело. А проблема проявлялась, когда сервер DNS включали после того, как включали сервер, на котором nginx был в роли прокси-сервера. Обычное состояние гонки. Даже не обязательно, чтобы это были зависимости процессов, проблема может быть даже на разных компьютерах.
Но да, есть ПО, которое корректно обрабатывает такие ситуации. Например, openvpn.
> Много ли системных сервисов используют dbus, кроме системде? Я ни одного не припоминаю, так что сделать этого, увы, не смогу.
Хм. Убейте демон dbus и попробуйте сделать что-нибудь через NetworkManager. ;)
Просто вот даже растерялся как-то, всё тупо работает, и никогда не задумывался, что там с сокетами на момент запуска... Ну скажем nginx и не подумает завершаться, если не достучится до сокета какого-нибудь php-fpm.
>> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода.
>> (ну и пробовал READY=1 через socat в bash, и вариант через python).
> socat-то конечно "проще", чем netstat -nxp | grep ...Сначала не обратил внимания, причём тут netstat вообще? Название сокета в переменной окружения есть. Права доступа я могу через консоль посмотреть.
>>> Чтобы реализовать то же самое на скриптах bash мне понадобилось бы гораздо больше времени и строчек кода.
>>> (ну и пробовал READY=1 через socat в bash, и вариант через python).
>> socat-то конечно "проще", чем netstat -nxp | grep ...
> Сначала не обратил внимания, причём тут netstat вообще?
> Название сокета в переменной окружения есть.
> Права доступа я могу через консоль посмотреть.Соображений тут много. Начнём с того, что файл unix-сокета может уже быть, но его не обязательно слушают. Проверяется легко: между bind() и listen() вставьте usleep в тысячу секунд. (Это я пишу для комментаторов выше, которые рекомендуют [ -S "$socket" ] в цикле).
Я берусь утверждать, что socat использовать для проверки сокета хуже по причине того, что он в обязательном порядке пытается что-либо послать, то есть непосредственно устанавливает соединение. В то же время netstat проверяет состояние сокета без установки соединения.
Вот Вы посылаете, как я понял, строку "READY=1" через socat. Откуда нам знать, что демон на той стороне корректно реагирует на это сообщение? Если уж использовать socat, то я бы воздержался от посылки чего бы там ни было, ограничившись чем-то вроде echo -n | socat - UNIX-CLIENT:/tmp/checker.socket
Это безопаснее, хотя и не лишено недостатков: что, если демон при отсутствии ввода после установки соединения зависает? Мне вот когда-то такой демон попадался. Давно, правда, дело было, я уже не вспомню название. Но такое бывает.
Посему во избежание проблем всё-таки правильнее имхо использовать netstat, грепая по имени сокета и слову LISTEN. Этот вариант безопасен и не вызывает проблем от слова совсем: грепнуть вывод netstat гораздо проще, чем разгребать возможные проблемы, связанные с использованием socat.
socat был необходим лишь для эксперимента, чтобы убедиться, что данные в сокет вообще уходят. То, что они приходят к демону понятно и так, т.к. не было возвращено ошибок. Соответственно на стороне сервера была исполнена read().Вообщем, обходной путь найден, но в systemd ошибка присутствует. systemd-notify абсолютно неработоспособна. Пока могу предполагать, что проблема из-за того, что systemd пытается определить принадлежность к cgroups по PID. Но делает это после того, как сообщение было получено. Соответственно, процесс уже завершился, а сообщение игнорируется, т.к. невозможно было определить cgroup. Идея интересная, - один сокет на все процессы, но реализация, похоже, неграмотная. Я бы в протокол добавил обязательно ожидание подтверждения от демона того, что сообщение получено. Блокирующийся read() не дал бы процессу завершиться и можно было бы определить его cgroup. Но как именно там реализовано пока не знаю.
Обходной путь - переписать скрипт c bash на python и использовать systemd.daemon.notify('READY=1'). Пока устраивает.
Отчёт об ошибке отправлен в Debian. Сам я пытался найти место, где происходит приём сообщений, но пока не нашёл. Код там нельзя назвать интуитивно понятным. Нашёл функцию, которая определяет cgroup по PID, но по её вызовам не нашёл абсолютно ничего полезного. Даже по слову READY я не смог найти место, где данная строка обрабатывается.
Учитывая, что тут любят придираться к мелочам, поправлю себя и уточню: read(), либо же recv().
автомонтирование флешек работает? В jessie сломали.
Не подтверждаю. Jessie, KDE, systemd, все работает.
> автомонтирование флешек работает? В jessie сломали.зато wget починили - а то у них была фирменная фишка в чётных версиях ломать wget - так было и в squeeze и в jessie
а прогрессбар при скачивание в несколько строчек?
> а прогрессбар при скачивание в несколько строчек?в том-то и дело, что починили :)
> автомонтирование флешек работает? В jessie сломали.Не то чтобы совсем сломали, но без systemd не работало. Полагаю, что не работает по-прежнему. Починить можно только пересборкой policykit без systemd или переходом на devuan.
Есть ли смысл переходить с Devuan? Есть ли значительные преимущества?
- 10 к интеллекту
+ 25% лайков на опеннете
Активная способность: рассказать всем как сильно ты ненавидишь systemd. Возможно использовать когда всем окружающим на$рать.
>> смысл переходить с Devuan?
> - 10 к интеллектуТ.е. использование системДы делает глупее. Что-то такое я подозревал.
> + 25% лайков на опеннетеЗасилье фанатов Лёни на опеннете трудно отрицать.
> Активная способность: рассказать всем как сильно ты ненавидишь systemd.Т.е. у системдышнеков наклонности мазохистов или же просто некоторые психологические отклонения, типа раздвоения личности? Спасибо за откровения, буду и далее держаться от них подальше!
Интересно чтобы он сказал про переход на runit. Наверное минус 90 к интеллекту.
*что бы
Ты не уловил суть) Системд хейтеры играются со своими девуанами, а затем переходят на настоящие дистрибутивы, засирая при этом все новости постами о том, как они этим недовольны)
Если Вас не волнует скорость загрузки системы, не интересуют новые версии ПО, и Вы не занимаетесь администрированием, - то нет, никакого смысла переходить нет.
> Если Вас не волнует скорость загрузки системы,Это вот так, да?
https://www.youtube.com/watch?v=hx30Z7_G-vk
> archbang - systemd vs openRC (speed load sytem)да не расстраивайтесь вы, ваш любимый системд только немного медленне ... хотя да, он же вроде вначале пропихивался именно под таким соусом - обеспечить быструю загрузку. Получается, Рыжий в Красной Шляпочке вас немножечко на***л, да? =)
> не интересуют новые версии ПО,
Про новые версии ПО - это конечно мечта всех Истинно Верующих Последователей Рыжего, но пока что еще далеко не всем сумели запихнуть свою привязку, хотя стараются, да:
https://github.com/tmux/tmux/issues/428
> With systemd 230 we switched to a default in which user processes started as part of a
> login session are terminated when the session exists (KillUserProcesses=yes).
> []
> Unfortunately this means starting tmux in the usual way is not effective, because it will
> be killed upon logout. There are a few option to avoid that, the best being:
> systemd-run --scope --user tmux
> This starts tmux as a scope unit under the systemd --user instance.
> It would be great if tmux could do this automatically. Probably the best way to do this would be to make the
> dbus call to org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. Seeскромно, ага. «мы тут подумали и Леннарт Неповторимый решил, что пора немного cломать поведение демонов, немогли бы вы вставить костыль в свою программу, чтобы мы могли и далее делать вид, что все в порядке?»
А вот что ответил автор тмукса:
> My concern is that we have a little function, daemon(), that does a simple little procedure to make
> a daemon that has worked basically unchanged across multiple platforms for maybe, what, 30 years?
> Now to do the same thing we need to add 150 lines of new, Linux-only code AND a library dependency.Ответил без должного почтения, да еще и отказом. Нехорошо то как!
> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the packageочешуеть
>> speaking as the Debian maintainer I'm okay with adding a dependency on libsystemd to the package
> очешуетьЭто проблемы мейнтейнера. Однако от автора требуют встроить поддержку дбаса. Причем, в лучших традициях этой наглой братии - не присылая хотя бы полусырой патч, нет:
> It would be great if tmux could do this automatically.
> Probably the best way to do this would be to make the dbus call to
> org.freedesktop.systemd1.Manager.StartTransientUnit directly from tmux. See
> https://github.com/systemd/systemd/blob/master/src/run/run.c... for how systemd-run
> does it, and https://www.freedesktop.org/wiki/Software/systemd/dbus/ for the description of the API.т.е. вот так мы делаем в системде, вот АПИ, вперед и с песней.
Ну, да, теперь они прут внаглую: мы апстрим и будь нам благодарен, что тебя с твоим г. не только заметили, но и указали на _твою_ недоработку (несовместимость с нашим божественным сисд!) и, да, наши гайдлайны (читай "скрижали") включают в себя обязательную несовместимость с остальными ОС, и ежеполугодичные ломания API, чтобы разработчикам не было скучно. Так что взял свой код и БЫСТРО ИСПРАВИЛ, ЯСНО?!! это _приказ_!Примерно так. Уважение? нет! скажите "спасибо", что вас матами не обложили.
А что касается dbus и зависимости на libsystemd так это... извиняйте, _дань прогрессу_
Вполне себе нормальный подход фанбоев от разработчиков сисд. Это не значит, что этих фанбоев не надо ногами по морде бить за умышленный саботаж на уровне экосистмы OpenSource. Но для этих убл*дков есть свой котёл по ту сторону добра и зла...
> в связи с чем запущена инициатива по проведению в этот день мероприятий, приуроченных к выходу Debian 9.0.Столы накрывать будут?
Ubuntu уже свой "фирменный" накрыла.
Поздно, Devuan уже вышел.
У меня опять шаблон рвётся:
- будет готово как только будет готово
- всё что не будет готово к 9 июня будет удаленоОдно из этих утверждений насквозь лживо.
Вот оно и будет готово, как только всё что не готово, будет удалено.
Стоит сейчас на ноут вместо убунты ставить? Или лучше арч?Все равно собираюсь на ssd пережать
Сиди на 14й убунте и разбирайся с гентой.
была 16ю04 теперь арч
> Все равно собираюсь на ssd пережатьЛучше используй "не ssd, а что-то человеческое"(с) опнет.
systemd когда выпилят тогда и праздновать будем!
поздно на arch уже