Системы инициализации Unix и Linux после SysV

[funca]

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

[dsrk_dev]

так-то это идеология UNIX на те-же архиваторы посмотри, tar обьединяет фалы в архив, bz2 сжимает архив.

[temujin]

Но для распаковки *.tar.bz2 достаточно команды tar -axvf file.

[redfs]

Запаковать тоже можно одной командой. tar -cjfv file.tar.bz2 file… Но при этом все равно работает связка tar + bzip2. Думаю, что worldxaker это имел в виду.

[mistergrim]

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

[redfs]

По большому счету сжатия у tar и сейчас нет. Все сжатие ( -z, -Z, -j… -I ) осуществляется подключаемыми внешними фильтрами. Сам по себе tar компрессией не занимается.

[dmitry_ch]

но тут случился systemd

Точно — «случился».

[zersh]

Было интересно. спасибо
в логировании видимо опечатка: cd log && mkdir mail
main?

[temujin]

Действительно, и спеллчек не заметил. Спасибо.

[miga]

Можно сколько угодно твердить мантру про философию UNIX, но правда в том, что _простые_ запускалки стартовых скриптов на самом деле не решают проблему инициализации и управления сервисами.

Нужно знать взаимные зависимости сервисов (чтобы при загрузке запускать их параллельно), неплохо бы воспользоваться всеми ништяками cgroups и т.д. Например, простейшая, казалось бы, задача — по PID процесса узнать, какой сервис за него отвечает — не решается нигде, кроме как в systemd. Так что как бы не говнили systemd за переусложненность, архитектурные проблемы и чего там еще, его появление — это _очень_ большое дело (и, безусловно, хорошее) для развития всей платформы.

[NaHCO3]

> Например, простейшая, казалось бы, задача — по PID процесса узнать, какой сервис за него отвечает — не решается нигде, кроме как в systemd.

Либо двумя строчками башскрипта. Взять полученный pid и записать его в файл.

[miga]

К сожалению, все не так просто и для SysV однозначного решения нет. Не все сервисы утруждают себя созданием PID-файлов, кроме того, очевидно, что у сервиса может быть больше чем один процесс. Да и вообще, PID-файлы решают обратную задачу — по имени сервиса найти процесс, а не наоборот. В общем, итоговое решение у меня заняло строчек двести, с использованием различных угадаек. В systemd же это решается тривиально, так как каждый сервис запускается в своей cgroup.

[temujin]

Философия или принципы Unix — это не мантра, а стратегия разработки ПО, которая по сей день актуальна. В этом отличие от мантры, которую повторяют, но ничего не делают или делают наоборот.

Как мне кажется многие обиды и непонимание возникли оттого, что стратегию стали разменивать ради тактических соображений. Именно это и означает отказ от принципов Unix, ради того, чтобы инит умел находить сервис по PID и стартовал ОС на 17% быстрее.

Параллельный запуск процессов уже многие иниты умеют (nosh, openRC, runit), также как и отслеживать зависимости. OpenRC имеет поддержку cgroups.

[grossws]

Параллельный запуск процессов уже многие иниты умеют (nosh, openRC, runit), также как и отслеживать зависимости.

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

OpenRC имеет поддержку cgroups.

Которая там была чисто для галочки "поддерживает cgroups". Возсожно сейчас что-то изменилось, но тогда это была профанация.

[temujin]

Никак не скажешь, что поддержка cgroups экспериментальная или профанация. Если есть конкретные примеры, давайте, а то так можно многие не доведенные до ума фичи назвать профанацией.

[grossws]

Посмотрите, что было к моменту голосования: https://wiki.gentoo.org/index.php?title=OpenRC/CGroups&oldid=17977. Была ровно одна фича, которая долгое время являлась киллер-фичей systemd.

[temujin]

Revision as of 06:36, 22 June 2013 by

К моменту голосования чего именно: инит системы Debian?

[grossws]

Да, извиняюсь, забыл указать. Изменения в этой части openrc очень удачно «совпали» с подготовкой к голосованию, емнип

[NaHCO3]

> openRC

Официально не поддерживает параллельный запуск. Эта фича является сильно экспериментальной. Некоторые сервисы не способы стартовать или остановиться корректно, и это отражено в багтрекере. Проблема так и не решена, вместо этого стоит пометка «а мы и не обещали вам, что всё будет работать».

[NaHCO3]

Ещё monit есть на поприще служб-бебиситеров.