Для тех, кто пробовал: чем BSD init не устраивает?

Тогда gdm кто? Менеджер сессий или оболочка?

Shadow> ./path/to/repeated/function.sh

И получается баш-спагетти, которое размазано по куче мелких файлов. Круто, чо.

Чорт, я до сих пор try-catch вставляю. На него даже макросы существуют, чтобы код не усложнять... Может, systemd и buffer overflow будет тогда заниматься?

Shadow> Я таки настаиваю, что супервайзинг - тупой костыль, появившийся из-за прорвавшихся в C/C++ ынтерпрайз жавакодеров.

Повторяю: идеальных программ не бывает и многое часто переписывается в угоду прогрессу. Автоматизация здесь только благо.

Ок, уговорил. Хорошие программы + бдительная система инициализации = двойной профит, systemd ok.

Shadow> Кстати, почему бы тогда, раз намного больше, не объединить его с libc?

Потому, что libc - это стандартная библиотека, а не система управления компонентами ОС. Впрочем, минималистичный вариант мог бы оказаться полезен, но они уже отдельно есть.

Shadow> Тогда gdm кто? Менеджер сессий или оболочка?

Менеджер сеансов X11. Он строго привязан только к X11 и не интегрируется в ОС. Если же кратко - это костыль. Так что logind - штука очень нужная, так как она унифицирует механизм логина на всех уровнях сразу.

К logind gdm привязан уже вроде?

Shadow> Хорошие программы + бдительная система инициализации = двойной профит, systemd ok.

Не система инициализации, а супервизор сервисов. Система инициализации тут же для того, чтобы не усложнять задачу и адекватно всё интегрировать.

Чорт, я до сих пор try-catch вставляю.

Дык все вставляют. Но отработка try-catch на верхнем уровне при экзепшене в глубине почти всегда дублирует функционал супервизора, а также может приводить к противоречивому состоянию сервиса при росте сложности оного.

Shadow> К logind уже вроде?

Ну да. Теперь к logind. И это правильно. На то есть две причины:

1. Графическая морда

2. Отвязывание от устаревшей концепции X11

Не мешало бы ещё kdm и lightdm привязать к logind, чтобы было всё едино.

Ну это уже вопрос к архитектору проекта.

Будущее за модульными и многофункциональными разработками

Сингулярити из каменг, хуле.

Не хочу ещё спамить, но мне кажется, все попытки переделать/заменить X11, всё портят. Оно нынче жрёт память как не в себя (раньше на 16 мб оперативки работало), и, САМОЕ ГЛАВНОЕ, из всех gui выпилены пиксельные шрифты. Даже в windows такого нет, пиксельные шрифты есть и могут использоваться. На вопрос, зачем мне пиксельные шрифты, отвечу: эмбеддед + хинтинг даже в windows часто сосёт.

Не мешало бы ещё kdm и lightdm привязать к logind,

xdm и wdm.

К тому, что systemd - это копипаста launchd чуть менее, чем полностью.

Shadow> Не хочу ещё спамить, но мне кажется, все попытки переделать/заменить X11, всё портят.

Попытки оставить X11 мешают линуксу выйти на мобильный рынок. Плюс, тормознутость иксов не даёт возможности реализовать tearless отрисовку без костылей.

Shadow> Оно нынче жрёт память как не в себя

Поэтому и нужно предельно упростить графическую часть. Тот же Wayland это поможет сделать.

Shadow> и, САМОЕ ГЛАВНОЕ, из всех gui выпилены пиксельные шрифты.

Ещё одна устаревшая концепция.

Shadow> Даже в windows такого нет, пиксельные шрифты есть и могут использоваться.

Windows славится своим legacy-кодом для обратной совместимости. Помнится ещё в Windows XP были куски для поддержки Win16 API. Но это не повод хранить и поддерживать legacy-слой в линуксе.

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

*facepalm*

Пиксельные шрифты рулят и многое упрощают.

Quasar

Осторожно, многие могут не понять твоей иронии. :)

портировать launchd на линукс

http://www.opennet.ru/opennews/art.shtml?num=38692

Не взлетит, в нём нет интеграции dbus!

А инструмент,... обеспечит при этом надёжность даже при использовании ненадёжного кода

Прекращай курить.

ААа1!!!! Квазар жжот :D

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

Особенно доставит в случае падения демона из-за невозможности подцепиться, скажем, к удаленной БД.

Удалённая БД супервизируется своим супер визором! А за кластером следит суперпупервизор systemdd!

А на самом деле, простая файлопомойка с, допустим, линуксовой 1С будет отлично рулится SystemV, и, скорее всего, так и будет на дебиане много лет (sysV остаётся поддерживаемым, без вопросов). А вот красноглазые десктопы и эзотерический ынтерпрайз будут только с systemd.

философские аспекты

не нужны

vasily_pupkin> ААа1!!!! Квазар жжот :D

А по делу сказать нечего что-ли? А то только и можете обсирать systemd и Поттеринга без оснований.

Shadow> А на самом деле, простая файлопомойка с, допустим, линуксовой 1С будет отлично рулится SystemV

И при этом systemd также хорошо справится с задачей.

Давно ты не писал ничего разумного. Это из-за оперы на локалхосте?

Это из-за оперы на локалхосте?

Неа, из-за неё я никогда не пишу чего-то запредельно тупого.

Особенно доставит в случае падения демона из-за невозможности подцепиться, скажем, к удаленной БД.

Как только линк к к БД вернётся, череда неудачных перезапусков завершится, и сервер будет работать в нормальном режиме, как будто ничего и не было.

Неа, из-за неё я никогда не пишу чего-то запредельно тупого.

4.2

Ну ок, может и не из-за неё…

В случае, если надо иметь 1С сервер двух разных версий (8.1 и 8.2, например), решение с systemd будет «чище» — сделать cp /usr/lib/systemd/system/srv1cv81.service /etc/systemd/system/ , поправить параметры запуска в полученной копии и это не затронет файлы оригинального пакета. А в SysV для этого придётся править скрипт запуска.

не знаю, с фига ли systemd хранит текстовые конфиги в lib, но всё указанное также справедливо для init скрипта.

Эзотерический энтерпрайз кое-где еще на rhel4 сидит, если там вообще линукс. Системд там дай бог чтоб хотя бы через 10 лет появился.

А во время этого даунтайма мы получим на почту рута шитшторм из десятков тысяч писем, а сервер уйдет в даун из-за выжирания ресурсов бесконечными попытками рестарта. Я специально посмотрел ман системд - там нет крутилки таймаута рестартов хотя бы задержки между попытками. Fail.

А во время этого даунтайма мы получим на почту рута шитшторм из десятков тысяч писем

Почему вас так заботят проблемы админов-дебилов, не осиливших настроить zabbix по таймеру?

а сервер уйдет в даун из-за выжирания ресурсов бесконечными попытками рестарта

«Ресурсы» — это электричество что ли? Или винчестер износится?

Я специально посмотрел ман системд - там нет крутилки таймаута рестартов хотя бы задержки между попытками. Fail.

А зачем? Электричество сервера сэкономить? Напиши новый restart strategy с шедулером и таймерами для systemd и отправь Лёне, он с радостью одобрит новый велосипед в init-процессе.

Показательно, что ни в одном нормальном супервизоре нет такой функции: ни в эрланге, ни в supervisord, ни в systemd. И даже потребности в ней не возникало ни разу.

Показательно, что нормальные люди выносят мониторинг и рестарт сервисов (с гибкой настройкой процессов) в отдельные демоны.

Пример нормального супервизора процессов для нормальных людей в студию.

В инитскрипте придётся городить спагетти на баше в этом случае. Разница на лицо.

Сейчас он тебе даст ссылку на s6 или на perp,которые ни в какой сравнение с возможностями systemd не идут, так как они не поддерживают модули вроде journald с тесной интеграцией.

Это Вы про обычный энтерпрайз, а не эзотерический.

Для моих задач хватает supervisord

Объясни, на кой мне менеджер процессов с интеграцией с journald, если в нем нет элементарных вещей? Есть настройка, какие сигналы игнорировать, но нет настройки вроде max_retries.

max_retries не имеет смысла для супервизора верхнего уровня дерева супервизоров.

Лол, опять наверное про Ubuntu.

Но это поцтеринговская неумелая копипаста

Это где всё в одном файле?

Хоть в сотне.