LINUX.ORG.RU

Февральские тезисы о планах развития systemd

 ,


2

4

На прошедшей конференции FOSDEM Леннарт Поттеринг огласил некоторые перспективы развития systemd:

  • Интеграция в systemd загрузчика gummiboot, поддерживающего технологию UEFI Secure Boot.
  • machined — менеджер регистрации виртуальных машин, спроектированный под впечатлением от Solaris Zones.
  • В подсистеме nspawn и смежных с ней ожидается больше возможностей для управления контейнерами, например, journald сможет собирать логи не только с хоста, но и с контейнеров.
  • Уже в следующей версии ожидается улучшенная поддержка Btrfs (подразделы и снапшоты Btrfs планируется использовать для изоляции отдельных приложений).
  • Поддержка HiDPI и Юникода в consoled.
  • Сервис-ориентированный фаерволл: можно будет задавать правила в привязке не к номерам портов, а к именам процессов.
  • Отпадёт нужда указывать путь к юниту для systemctl-cat; systemctl-edit позволит редактировать юниты и после сохранения изменений автоматически перезапускать соответствующие сервисы.
  • nss-getmyhostname — функция для получения имени хоста на stateless-системах.
  • Утилита ping gateway позволит автоматически определить все доступные сетевые интерфейсы и проверить их статус командой ping.
  • Развитие networkd и собственной библиотеки для работы с DHCP (совместимой с dhcpv4 и dhcpv6).
  • Комбинирование nspawn и networkd позволит легко конфигурировать сеть для контейнеров.
  • Создание средств для широкого системного аудита, интегрированных в journald. Например, станет возможным логировать все системные вызовы к файлу /etc/passwd.
  • Движение в сторону stateless-систем, у которых только /usr доступен на чтение и запись, а /etc и /var будут автоматически заполняться systemd.
  • journald-remoting — удалённая работа логгера через HTTP. Поддержка в journald моделей pull и push: при pull выполняется запрос HTTP GET для получения потока JSON, а при push данные передаются в другой экземпляр journald при помощи HTTP POST.
  • Возможность определения для сервисов минимальных пространств имён и sandbox-изоляции: доступ к некоторым разделам и каталогам только на чтение, сокрытие устройств в /dev, приватный /tmp для каждого сервиса, и др.
  • timesyncd в качестве замены ntpd.
  • Автоматическое определение разделов GPT, не нуждающееся в указании их в fstab.
  • Поддержка перезапуска демонов без потери их состояния (посредством сохранения оного на диск).

>>> Подробности



Проверено: Shaman007 ()
Ответ на: комментарий от kir2yar

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

Так а какая разница-то в этих деталях. Это одна сущность. Я еще раз обращаю ваше внимание: всё «нужное» засунуто в сам systemd при помощи гвоздей, скотча и клея, а не подсоединено на проводах через стандартизированные разъёмы.

Когда настанет пора остановиться? Когда станет возможым запустить LibreOffice на systemd bare bones?

devzero ()
Ответ на: комментарий от kir2yar

> Вас послушать, так надо выпилить все *sh скрипты из системы, так как они могут содержать плохой код.

Ну все - не все, а вот из критических подсистем - было-бы не плохо.

Я ж и говорю, магическая-мистическая боязнь sh. «sh-код всегда плох, даже если написан хорошо». Каинова печать на нём. Или ведьмино проклятие.

devzero ()
Ответ на: комментарий от anonymous

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

Хотя какое это нафиг сообщество. Вон, например, devzero — профессиональный провокатор. Добился того, что его четыре человека из пяти в этом треде послали найух, и теперь радуется. Или этот, как там его, Мойша Либерман, с совершенно аналогичной тактикой поведения. И таких пол-ЛОРа.

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

intelfx ★★★★★ ()
Ответ на: комментарий от devzero

Я вообще не верю в способности «дистроделов» от коммунити. Дистрибутив, как правило, держится на 2-3 специалистах, которые задают уровень. Если они теряют интерес или уходят, дистрибутив теряет смысл.

А если им понравилось отличное от классического инита решение?

Утилита написана, она работает, задачи, для которых была создана, полностью реализует.

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

Но оно мне надо? Денег мне за это никто не заплатит

Если не надо, то почему ты тут жалуешься? Людям надо, они делают. Тебе не надо - значит и не ной.
А то получается: «хочу быть халявщиком, что бы все делали так как я хочу, но мне для этого не приходилось тратить свои силы!»

Что касается if [ -f /etc/default/named ], вы просто не владеете этим ЯП, и вот всё. Обычная и понятная любому знакомому с sh конструкция. Придуманная как раз ДЛЯ ЧИТАБЕЛЬНОСТИ, чтобы скобки чётко оформляли условие.

Возможно. Однако использование конструкций, которые похожи на аналоги из других ЯП - резко повышают читабельность кода.
В идеале должно вообще быть что-то вроде:
if ( FileExists /etc/default/named ) {}

Админ должен иметь возможность заточить систему общего назначения под свои нужды произвольным образом,

Те, кому это действительно нужно - затачивают. Им systemd не помеха. Гном на сервере или встраиваемом устройстве не используют. )

Так ведь и в sh есть возможность защититься от таких опечаток. Написать стандартные библиотеки алгоритмов, заставить всех ими пользоваться... ага. Заставьте, как же. :)

Да, начнут ныть, что у них отбирают гибкость. Или тупо не осилят.

С чего вы взяли, что безопасными возможностями systemd будет заставить пользоваться проще, чем какими-либо иными?

Серьезно ошибиться в декларативной конфиге - сложнее, чем ошибиться в программе для тьюринг-полного ЯП.

Замечательно. Хорошая вещь. А гвоздями к systemd прибивать зачем? Код для обработки tmpfiles.d можно за вечер написать на любом ЯП: хоть на Си, хоть на sh, хоть на питоне.

Люди делали для себя, им так удобней. Если вещь простая - то не понимаю в чем проблема ее написать для другого инита?

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

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

kir2yar ()
Ответ на: комментарий от anonymous

«Ещё они латентные геи!»

И активных это бесит.

anonymous ()
Ответ на: комментарий от intelfx

Я же пропагандист проклятый, приспешник майкрософта и вообще цель у меня одна — внести разлад в сообщество

вот... а хоть где то правду сказал :)

anonymous ()
Ответ на: комментарий от intelfx

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

Хотя какое это нафиг сообщество. Вон, например, devzero — профессиональный провокатор. Добился того, что его четыре человека из пяти в этом треде послали найух, и теперь радуется. Или этот, как там его, Мойша Либерман, с совершенно аналогичной тактикой поведения. И таких пол-ЛОРа.

http://www.yktimes.ru/wp-content/uploads/2013/12/krugom-vragi-foto-forum.ixbt...

devzero ()
Ответ на: комментарий от devzero

Логически это одна сущность. PID1 systemd бессмысленен без обвязки, а обвязка бессмыслена без использования PID1 systemd.

Если бы еще был смысл в sysvinit или ruint без обвязки...

Давай возьмем sysvinit/runit, приплюсуем к нему баш и весь coreutils, все шеллскрипты и посмотрим, кто толще?

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

Какой объем кода должен выполниться под sysvinit/runit для этого, по сравнению с systemd?

kir2yar ()
Ответ на: комментарий от anonymous

Аноним - не личность, а местная домашняя зверюшка.

kir2yar ()
Ответ на: комментарий от kir2yar

рунит таки есть недостатки - банальное неумение cgroups

croups не надо уметь :)
croups это перпендикулярная к системе инициализации вещь. Ее хоть к чему можно прикрутить.
Дело в том, что к runit (или к sysvinit whatever) ее можно прикрутить, а потом, если не понравится, можно и открутить.
А к systemd она уже прибита, гвоздями. Хрен открутишь. Потому что за тебя уже подумал гений и гений решил что тебе это нужно палюбас.

То же касается использования баша или ини-стайл файлов.
К runit можно прикрутить хоть баш, хоть неведомую хрень с цветомузыкой.
Было !/bin/bash
стало !/bin/myveryowninistyleshitcosilikeitfuckyou.binary
myveryowninistyleshitcosilikeitfuckyou.binary должна быть доступна при загрузке и должна уметь парсить столь любимые Вами ини файлы. Runit-у пофиг.
Systemd - подумал и решил, что вам нужен конкретно ини-стайл и никак иначе, с миллионом всякой хрени типа IfIDontCareAboutJustDontEatThatCake=true
Это просто пипец что должно быть у человека в голове.

Касательно rm -rf
Скажите - Вы реально не понимаете как можно «сделать харашо» используя стандартные средства?
Даже вариантов нет?
Ну типа сделать обертку, которая получит определенные права на определенную папку и обломится, если ее попросить удалить что-нибудь другое.
Есть и другие, гораздо более умные варианты.
И почему нужно удалять что-либо при инициализации системы - можете мне объяснить?
Извращаться можно и гораздо более интересными способами.
Но зачем?! (с)

anonymous ()
Ответ на: комментарий от kir2yar

Что касается if [ -f /etc/default/named ], вы просто не владеете этим ЯП, и вот всё

В идеале должно вообще быть что-то вроде: if ( FileExists /etc/default/named ) {}

Да ну?

А я думаю что в идеале

If  My.Computer.FileSystem.FileExists("etc/default/named")  Then
...
End If
или так
if FileExists("etc/default/named")
then ;

А что ты написал - ой не похоже на «аналоги из других ЯП» :)


Как жаль что создатели баша не поинтересовались у kir2yar как надо им сделать...

anonymous ()
Ответ на: комментарий от kir2yar

получается ты тупее зверюшки? :)

anonymous ()
Ответ на: комментарий от intelfx

Вон, например, devzero — профессиональный провокатор

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

smith ()
Ответ на: комментарий от anonymous

«получается ты тупее зверюшки? :)»

Нет, он дикий грызун-вредитель.

anonymous ()
Ответ на: комментарий от kir2yar

А вот этого как-раз...

Давай возьмем sysvinit/runit, приплюсуем к нему баш и весь coreutils, все шеллскрипты и посмотрим, кто толще?

Делать и не нужно. По отдельности bash может быть использован где угодно и иначе чем в обсуждаемых задачах. Без coreutils жизнь в Linux вообще не мила будет и миспользуются они как и bash не только для руления демонами.

Вы же не предлагаете в пределах systemd реализовать bashd, или из набора coreutils — psd, cpd, dird, mknodd, (... всесь набор, входящий в coreutils)? Вы же это не серьёзно, я надеюсь? :))) Тогда уже кто-нибудь, реализуйте господину Поттерингу lsd и пусть он угомонится? :)))

Moisha_Liberman ()
Ответ на: комментарий от kir2yar

А ведь точно тупее зверюшки...

Давай возьмем sysvinit/runit, приплюсуем к нему баш и весь coreutils, все шеллскрипты и посмотрим, кто толще?

Давай из дистрибутива с системд выкинем баш и весь coreutils, все шеллскрипты и посмотрим кто вообще сможет на этом работать...

:)

anonymous ()
Ответ на: комментарий от kir2yar

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

Крайне сомнительно, чтобы от runit отказывались в пользу systemd. Полагаю, что большая часть пользователей systemd — это те, за кого решил кто-то другой. Раньше за них решали в пользу sysvinit, теперь решили в пользу systemd. Пользователь такого инита — категория пассивная.

Если не надо, то почему ты тут жалуешься? Людям надо, они делают. Тебе не надо - значит и не ной.
А то получается: «хочу быть халявщиком, что бы все делали так как я хочу, но мне для этого не приходилось тратить свои силы!»

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

Если не надо, то почему ты тут жалуешься?

Вот, кстати, еще один устойчивый признак приверженцов systemd. Они не верят, что критика программного продукта может быть просто критикой. Им обязательно надо увидеть жалобы, наезд, в общем всё то, к чем, вероятно, сами привыкли. Хорошо сочетается с постом intelfx выше.

Возможно. Однако использование конструкций, которые похожи на аналоги из других ЯП - резко повышают читабельность кода.
В идеале должно вообще быть что-то вроде:
if ( FileExists /etc/default/named ) {}

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

Второе. Вам мешают сделать FileExists() { test -e «$1» ; return $? } и пользоваться? Нет, никто не мешает. Но вы предпочтёте изобрести ручку за миллион долларов вместо того, чтобы взять карандаш.

Дух этой ручки просто пронизывает весь проект сверху донизу.

Люди делали для себя, им так удобней.

Вот в том и дело. «Делать для себя как удобнее» и «делать систему общего назначения, удобную для существующей индустрии» — вещи настолько разные, что нелепо сравнивать. И так всё время. Как замах - так «мы делаем решение энтерпрайз-класса, бла-бла-бла, бла-бла-бла, бла-бла-бла, бла-бла-бла», как удар и очередной промах мимо цели - так «мы делаем как добнее нам, отстаньте, мы вас вообще не трогали!»

Беответственность.

Люди делали для себя, им так удобней. Если вещь простая - то не понимаю в чем проблема ее написать для другого инита?

Проблемы написать нет. Проблемы есть в том, что:

  • Таких «вещей» systemd включает сотню, из которой десяток будет хорошими идеями, которые вообще незачем засовывать в systemd и вообще в какой-либо инит, они имеют самостоятельную ценность, других пара десятков — перспективные разработки, которые зачем-то скотчем примотаны к systemd и си-группам, а остальное — велосипеды или костыли. И всё это замешано в винегрет, попробуй сходу отдели одно от другого. В одной куче и бинарные программные интерфейсы, и форматы данных, и протоколы обмена, и чёрт еще знает что.
  • Сам подход «мы делаем для себя, нам так удобно, отвалите» вполне исчерпывающе характеризует, эээ... небрезгливость авторов и несопобность писать красивый (а значит, хотя бы немного качественный) код. У квалифицированного разработчика такая свалка будет вызывать брезгливость и желание растащить её на 10 самостоятельных сущностей. У неквалифицированного такого профессионального чутья нет.

Если читать новости в оригинале - то именно так они звучат у системд.

Увы, нет. В блог виновника торежства я иногда заглядываю, и заметки его читаю в оригинале.

devzero ()
Ответ на: комментарий от devzero

Нежелание разбираться,

В shell. Это старо, немодно и не молодёжно. Хочется нового. Новые машины (автомобили) офигенны. Беда только в том, что принципы, на которых двигатель внутреннего сгорания работает ой какие древние. Сомневающимся замечу — да-да-да, я в курсе про теслу и прочие электромобили. Посчитайте число авто в мире (хотя бы легковых) и прикиньте сколько надо лития для того, чтобы пересадить всех хотя бы на гибриды. Поотпустит маленько.

Moisha_Liberman ()

Буквально всё, что есть в Systemd, это костыли разной степени унификации.

HyperCOGENT ()
Ответ на: комментарий от kir2yar

Если бы еще был смысл в sysvinit или ruint без обвязки...

Смысл ruint — быть супервизором указанного списка процессов. В этой функцией он справляется без всякой обвязки.

Давай возьмем sysvinit/runit, приплюсуем к нему баш и весь coreutils, все шеллскрипты и посмотрим, кто толще?

А давайте не будем заниматься бессмыслецей?

Какой объем кода должен выполниться под sysvinit/runit для этого, по сравнению с systemd?

Вы объём кода собираетесь измерять в строках кода, в тактах CPU, в количестве fork(), в объеме mmap()-нутых исполняемых страниц, в пришествиях дьявола, в попугаях? Чушь нести не надо.

devzero ()
Ответ на: комментарий от devzero

Объём кода будет меньше тогда, когда костылей будет меньше.

HyperCOGENT ()
Ответ на: комментарий от anonymous

То же касается использования баша или ини-стайл файлов. К runit можно прикрутить хоть баш, хоть неведомую хрень с цветомузыкой. Было !/bin/bash стало !/bin/myveryowninistyleshitcosilikeitfuckyou.binary myveryowninistyleshitcosilikeitfuckyou.binary должна быть доступна при загрузке и должна уметь парсить столь любимые Вами ини файлы. Runit-у пофиг. Systemd - подумал и решил, что вам нужен конкретно ини-стайл и никак иначе, с миллионом всякой хрени типа IfIDontCareAboutJustDontEatThatCake=true Это просто пипец что должно быть у человека в голове.

Касательно rm -rf Скажите - Вы реально не понимаете как можно «сделать харашо» используя стандартные средства? Даже вариантов нет? Ну типа сделать обертку, которая получит определенные права на определенную папку и обломится, если ее попросить удалить что-нибудь другое. Есть и другие, гораздо более умные варианты. И почему нужно удалять что-либо при инициализации системы - можете мне объяснить? Извращаться можно и гораздо более интересными способами. Но зачем?! (с)

+ много

Аноним точно описал суть.

devzero ()
Ответ на: комментарий от devzero

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

HyperCOGENT ()
Ответ на: комментарий от anonymous

И активных это бесит.

Ну ты уж держи себя в руках, не бесись при всех.

anonymous ()
Ответ на: комментарий от anonymous

«Ну ты уж держи себя в руках, не бесись при всех.»

Я за systemd, мне беситься нечего. От содомии шелл-портянок я с радостью отказался.

anonymous ()
Ответ на: комментарий от devzero

У неквалифицированного такого профессионального чутья нет.

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

Изумительная вещь.

devzero ()
Ответ на: комментарий от anonymous

От содомии шелл-портянок я с радостью отказался.

А, понятно, то есть был содомитом, но теперь отказался, значит стал латентным содомитом, как я и писал выше. ЧТД.

anonymous ()
Ответ на: комментарий от kir2yar

Угу...

Ну все - не все, а вот из критических подсистем - было-бы не плохо.

А какие подстстемы будем считать критическими? Для кого-то тот же bind является критической подсистемой, а для кого-то веб-сервера. Кстати, приведённый запускатор бинда говорит только о том, что код бинда надо было бы дааавно уже освежить.

Пора решать проблемы, которые накопились у классических инит-систем.

Т.е., классические инит-ситсемы не работали и демоны не запускались? И да, все задачи уже решены, осталось вот только инит вылизать и всё. Пресловутая домохозявка сможет накатить генточку, снеся проклятый некрософт? :))) Ну и в линукс таки завезли уже игорей, не переиграть?

Moisha_Liberman ()
Ответ на: комментарий от anonymous

«А, понятно, то есть был содомитом, но теперь отказался, значит стал латентным содомитом, как я и писал выше. ЧТД.»

Бурлит от того, что ты остаешься активным?

anonymous ()
Ответ на: комментарий от anonymous

Бурлит от того, что ты остаешься активным?

Да не, я ж не за себя, за тебя перживаю. Латентные формы они самые нехорошие, сорвёшся же и понеслась опять.

anonymous ()
Ответ на: комментарий от devzero

А ещё оно старательно пытается завязать на себя остальные проекты, которые становятся неработоспособными без этой дряни и тащат её в зависимостях, хотя эта зависимость просто высосана из пальца.

А ещё, я, например, вообще понять не могу, какого хрена системгфилы не удовлетворяются запуском своего любимого systemd из какого-нибудь стандартного скриптика /etc/init.d/systemd И ломать ничего не надо, и systemd ихний запущен со всеми пирогами, раз уж он им так нужен. Или им принципиально нужно PID1 захватить?

На самом деле, если серьёзно, то уже скоро мы увидим первый Linux в котором невозможно запустить ничего самособранное и неодобренное чужим дядей. Уже не только на какой-нибудь Tivo, а на самом обычном писюке.

UEFI->SecureBoot->loaderd->linuxkerneld->systemd->только одобренный софт.

Гарантирую, что вот-вот уже в systemd появится проверка подписанности запускаемых софтин и конфигов. Если уже не появилась.

Stanson ★★★★ ()

"Не сломалось — не чини" или "На SysVInit 40 лет у всех всё прекрасно работало, зачем что-то менять" ©

Расскажу-ка я историю борьбы с одним багом.

Заметил я давеча, что proftpd на wheezy в понедельник может оказаться не запущенным. Пошёл разбираться — умирает на рестарте. Пошёл смотреть, кто рестартит — logrotate. Пошёл в гугл, сразу нашёл баг, связанный с гонкой, — https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675081 . Починено в 1.3.5, в wheezy 1.3.4, эх, грусть-печалька, пошёл править инит скрипт вручную. Подождите, но в комментариях к багу сказано, что если добавить sleep 2 между stop и start, то, хоть это и некрасиво, но работать будет, а в инит-скрипте sleep 2 уже есть, почему же я на баг нарвался, хотя он уже вроде как workaround'нут? Имитируем высокую загрузку, запускаем /etc/init.d/proftpd restart — действительно, работает нормально. Но почему в logrotate тогда падает? Смотрим в конфиг, а тама

postrotate
                # reload could be not sufficient for all logs, a restart is safer
                invoke-rc.d proftpd restart 2>/dev/null >/dev/null || true
Ху из мистер invoke-rc.d? Ага, какая-то баш портянка на 500+ строк, копирайт аж 2000 года. Чего делает, не очень понятно, но, вроде, в итоге запускает инит-скрипт с указанной командой. А стоп, не с указанной — на restart он передаёт нифига не restart, а последовательно stop и start. Между которыми, естественно, никаких sleep нет и гонка никуда не девается. Костыли и велосипеды. Костыли в велосипедах и велосипеды из костылей.

redgremlin ★★★★★ ()
Ответ на: комментарий от Stanson

А ещё, я, например, вообще понять не могу, какого хрена системгфилы не удовлетворяются запуском своего любимого systemd из какого-нибудь стандартного скриптика /etc/init.d/systemd И ломать ничего не надо, и systemd ихний запущен со всеми пирогами, раз уж он им так нужен. Или им принципиально нужно PID1 захватить?

Кстати, да. Лол. Приспособить systemd, запущенный от пользователя, в качестве менеджера иксового сеанса они смогли. А рулить демонами, запускаемыми от рута, обязательно надо с PID 1. Абсурд абсурда.

devzero ()

Сейчас тебе расскажут, что так и надо и ты сам дурак, а если ещё и не можешь поправить скриптец руками и вставить очередной sleep 2 в стопятьсотпервое место — то тысячу раз дурак.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от kir2yar

Собственно, *BSD не гадят в инит.

Видимо, поэтому systemd вызывает мысль «ненужен».

А в RedHat и systemd засрут, так как многое «захардкожено», а кому-то понадобится «гибкость» из коробки и новый шелл скрипт... И всё г...о по новой, и systemd 2.0...

Shadow ★★★★★ ()
Ответ на: комментарий от devzero

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

Кстати, в 90% домашних юзкейсов в качестве менеджера иксового сеанса обсолютно рулит nodm, которому не только systemd не нужен, но и всякие *kit.

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

Stanson ★★★★ ()
Ответ на: комментарий от intelfx

Я тут выше кидал ссылки на скрипты без sleep.

Shadow ★★★★★ ()

Костыли и велосипеды. Костыли в велосипедах и велосипеды из костылей.

Чорт... Неужели только слака и *BSD, или RH с systemd сведут костыли к минимуму?

Ну и у нормальных SysV, что работали 40 лет, костылей таких адовых не встречается, ЕМНИП... (старая солярка, например)

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от Stanson

Не, эт не те сеансы. Ты про display manager.

А есть еще session manager. Это тот, кто запустит все клиентские процессы - wm, панельку, и все прочее, что тебе нужно для работы - а потом всё это убъет, когда надо выйти.

devzero ()

Ху из мистер invoke-rc.d?


по сути тоже самое, что и /etc/init.d/

А стоп, не с указанной — на restart он передаёт нифига не restart, а последовательно stop и start.

Это легко решается заменой на

invoke-rc.d proftpd stop && invoke-rc.d proftpd start
Но что-то мне говорит, что у вас proftpd как-то не тривиально работает. На моих серверах в 7.* proftpd ниразу не падали.

smith ()

Re: "Не сломалось — не чини" или "На SysVInit 40 лет у всех всё прекрасно работало, зачем что-то менять" ©

Ок.
Это не единственный пример того, как в сложной системе может что-то сломаться и сразу хрен поймешь как все эти пять пальцев свернулись в фигу.
Ок, sysvinit с его портянками на баше недостаточно хорош.
Давайте его выкинем. Давайте.
Давайте вместо него вкрячим что-нибудь модное, волшебное, делающее нам хорошо. Давайте, не возражаю.
Что вкрячивать будем?
Имеющиеся в наличии опции:
- очередная монструозная хрень пытающаяся альтернативными портянками (новый, модный ини-стайл, не дай себе засохнуть!) решать проблемы портянок уже изношенных
- файст, лайт, готовый взаимодействовать с чем угодно какой-нибудь там runit, s6, perp, nosh, whatever
Ну кагбэ выбор очевиден, нет?
НетЪ!
Мыши плакали, кололись...

anonymous ()
Ответ на: комментарий от Shadow

Никто не спорит, что и на шелле можно писать хорошо.

Тут другой тезис опровергается: мол «не ломалось — не трожь». Так вот, оказывается, ломалось. А уже каким способом это чинить — выбор того, кто будет чинить, не так ли?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Сдуру можно и хер сломать.
Всё, Вы уже побежали менять половую принадлежность хирургическим путем? Или есть альтернативы?

anonymous ()
Ответ на: комментарий от smith

Это легко решается заменой на

Наоборот. Проблема как раз в том, что invoke-rc.d не передаёт restart, а запускающий скрипт починили только для этой команды.

На моих серверах в 7.* proftpd ниразу не падали.

Почитай описание бага. Падают, если в момент рестарта система под нагрузкой. Вот тот же баг в убунте — https://bugs.launchpad.net/ubuntu/ source/proftpd-dfsg/ bug/1246245

redgremlin ★★★★★ ()
Ответ на: комментарий от devzero

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

Stanson ★★★★ ()
Ответ на: комментарий от Shadow

Ну и у нормальных SysV, что работали 40 лет, костылей таких адовых не встречается, ЕМНИП... (старая солярка, например)

Это всё от безблагодатности. sysvinit и был классическим супервизором: запускал процессы по inittab, а если они умирали, перезапускал их. Т.к. инит был родителем демонов, он знал, когда демон живой, а когда дохлый. Но ему не хватало конфигурируемости.

Тогда благородные доны из AT&T вместо того, чтобы доработать init, придумали запускать и останавливать демоны sh-скриптами, а ссылки на скрипты хранить в отдельном каталоге. Т.к. скрипты запускали демонов в режиме двойного fork()-а, то никакого родителя, который бы знал время жизни демонов, быть уже не могло. А PID-ы запущенных демонов решено было складывать в специальные файлики. И заверте...

С тех пор так и живём.

Понятное дело, что люди поособразительнее уже давно решили эту проблему: есть и daemontools (не путать с одноименной виндовой читалкой iso-образов), и runit, и minit, и другие супервизоры, которые спроектированы правильно, а не через ж^W PID-файлы. В макоси этим занимается вообще целый комбаин launchd, объединяющий в себе супервизор демонов, крон и следилку за появлением новых файлов в заданных каталогах.

Но 20 слишним лет инерция мышления заставляет буратин толкать вермишель на PID-файлах в RH, Debian и прочие-всякие openSuse, вместо того, чтобы просто выбросить этот сломанный велосипед. Энтерпрайз, фигли.

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

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

devzero ()
Ответ на: комментарий от redgremlin

Это легко решается заменой на

Наоборот. Проблема как раз в том, что invoke-rc.d не передаёт restart, а запускающий скрипт починили только для этой команды.

На моих серверах в 7.* proftpd ниразу не падали.

Почитай описание бага. Падают, если в момент рестарта система под нагрузкой. Вот тот же баг в убунте — https://bugs.launchpad.net/ubuntu/ source/proftpd-dfsg/ bug/1246245

И да, это ещё раз доказывает, что костыли вредят.

HyperCOGENT ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.