0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Как известно,<strong>SystemV</strong>и<strong>systemd</strong>представляют собой два разных метода запуска операционной системы Linux. Но сценарий запуска<strong>SystemV</strong>и демона<strong>init</strong>- это, все же, старый метод, тогда как юниты<strong>target</strong>в<strong>systemd</strong>- метод более новый. Не секрет, что сегодня большая часть современных дистрибутивов применяют для запуска, управления процессами и завершения работы именно подсистему<a>systemd</a>, присутствующую почти в каждом аспекте современного Линукса. Однако есть и те, кто так не делает. Дело в том, что до сих пор ряд сисадминов и создателей дистрибутивов предпочитают "старый добрый" SystemV. В принципе, их можно понять, ведь преимущества существуют у обоих методов.</p>
1
<p>Как известно,<strong>SystemV</strong>и<strong>systemd</strong>представляют собой два разных метода запуска операционной системы Linux. Но сценарий запуска<strong>SystemV</strong>и демона<strong>init</strong>- это, все же, старый метод, тогда как юниты<strong>target</strong>в<strong>systemd</strong>- метод более новый. Не секрет, что сегодня большая часть современных дистрибутивов применяют для запуска, управления процессами и завершения работы именно подсистему<a>systemd</a>, присутствующую почти в каждом аспекте современного Линукса. Однако есть и те, кто так не делает. Дело в том, что до сих пор ряд сисадминов и создателей дистрибутивов предпочитают "старый добрый" SystemV. В принципе, их можно понять, ведь преимущества существуют у обоих методов.</p>
2
<h2>Что же не так с systemd?</h2>
2
<h2>Что же не так с systemd?</h2>
3
<p>Почему<strong>systemd</strong>порой вызывает противоречивые реакции у технических специалистов и системных администраторов? Проблема в том, что systemd является ответственным за<strong>очень большое количество различных процессов и задач</strong>. А такая универсальность, как считают некоторые сисадмины и разработчики, уже является нарушением главного принципа, который говорит о том, что программы должны быть небольшими, каждая должна делать что-то одно и делать это хорошо. В результате некоторые высказываются против этого демона и отказываются от его использования, отдавая предпочтение классическим решениям.</p>
3
<p>Почему<strong>systemd</strong>порой вызывает противоречивые реакции у технических специалистов и системных администраторов? Проблема в том, что systemd является ответственным за<strong>очень большое количество различных процессов и задач</strong>. А такая универсальность, как считают некоторые сисадмины и разработчики, уже является нарушением главного принципа, который говорит о том, что программы должны быть небольшими, каждая должна делать что-то одно и делать это хорошо. В результате некоторые высказываются против этого демона и отказываются от его использования, отдавая предпочтение классическим решениям.</p>
4
<p>Фактически,<strong>systemd</strong>представляет собой комплексную систему больших исполняемых файлов, причем их логику не понять, не имея доступа к исходному коду. Конечно, systemd - open-source проект, поэтому проблемы с доступом к коду отсутствуют, однако все это не очень удобно.</p>
4
<p>Фактически,<strong>systemd</strong>представляет собой комплексную систему больших исполняемых файлов, причем их логику не понять, не имея доступа к исходному коду. Конечно, systemd - open-source проект, поэтому проблемы с доступом к коду отсутствуют, однако все это не очень удобно.</p>
5
<p>И все же, как считают некоторые,<strong>systemd</strong>своим появлением отчасти опровергает базовые принципы Linux-философии. В качестве бинарного файла systemd закрыт от прямого редактирования/просмотра системными администраторами. Ну и, повторим: эта подсистема пытается "делать все", к примеру, управлять запущенными службами. Хотя, конечно, если сравнивать с SystemV, systemd предоставляет намного больше информации о состоянии.</p>
5
<p>И все же, как считают некоторые,<strong>systemd</strong>своим появлением отчасти опровергает базовые принципы Linux-философии. В качестве бинарного файла systemd закрыт от прямого редактирования/просмотра системными администраторами. Ну и, повторим: эта подсистема пытается "делать все", к примеру, управлять запущенными службами. Хотя, конечно, если сравнивать с SystemV, systemd предоставляет намного больше информации о состоянии.</p>
6
<h2>Так чем же хорош SystemV?</h2>
6
<h2>Так чем же хорош SystemV?</h2>
7
<p>Во-первых, SystemV является более доступным. Запуск осуществляется посредством bash-скриптов. После запуска ядром init, скомпилированный бинарный файл<strong>init</strong>выполняет запуск скрипт<em>rc.sysinit</em>, выполняющий много задач в целях инициализации системы. Далее, после завершения<em>rc.sysinit</em>,<strong>init</strong>выполняет запуск<em>/etc/rc.d/rc</em>, который уже запускает разные демоны. Эти демоны определяются сценариями запуска<strong>SystemV</strong>в<em>/etc/rc.d/rcX.d</em>, причем "X" здесь - это уровень выполнения (runlevel).</p>
7
<p>Во-первых, SystemV является более доступным. Запуск осуществляется посредством bash-скриптов. После запуска ядром init, скомпилированный бинарный файл<strong>init</strong>выполняет запуск скрипт<em>rc.sysinit</em>, выполняющий много задач в целях инициализации системы. Далее, после завершения<em>rc.sysinit</em>,<strong>init</strong>выполняет запуск<em>/etc/rc.d/rc</em>, который уже запускает разные демоны. Эти демоны определяются сценариями запуска<strong>SystemV</strong>в<em>/etc/rc.d/rcX.d</em>, причем "X" здесь - это уровень выполнения (runlevel).</p>
8
<p>Во-вторых, кроме самого init, все эти демоны и скрипты являются открытыми и легкочитаемыми. На практике не составляет большого труда эти скрипты изучить, чтобы понять, как каждый из них работает, и что конкретно происходит в процессе запуска ОС (но вряд ли кто-либо из сисадминов очень часто этим занимается).</p>
8
<p>Во-вторых, кроме самого init, все эти демоны и скрипты являются открытыми и легкочитаемыми. На практике не составляет большого труда эти скрипты изучить, чтобы понять, как каждый из них работает, и что конкретно происходит в процессе запуска ОС (но вряд ли кто-либо из сисадминов очень часто этим занимается).</p>
9
<p>В-третьих, каждый запускаемый скрипт нумеруется таким образом, чтобы запускать нужную службу в конкретной последовательности. Что касается служб, то они запускаются последовательно и по одной за один раз.</p>
9
<p>В-третьих, каждый запускаемый скрипт нумеруется таким образом, чтобы запускать нужную службу в конкретной последовательности. Что касается служб, то они запускаются последовательно и по одной за один раз.</p>
10
<h2>Два слова о муках выбора</h2>
10
<h2>Два слова о муках выбора</h2>
11
<p>Да, между SystemV и systemd существуют противоречия, однако основная причина этому следующая: между ними нельзя выбирать на уровне системного администрирования. Почему? Да потому, что выбор уже сделали за вас создатели дистрибутивов и упаковщики. И сделали они это не без веских оснований: например, у замены<strong>init</strong>по причине его слишком инвазивной природы, очень много трудностей и последствий, а справиться со всеми ими весьма сложно вне создания дистрибутива.</p>
11
<p>Да, между SystemV и systemd существуют противоречия, однако основная причина этому следующая: между ними нельзя выбирать на уровне системного администрирования. Почему? Да потому, что выбор уже сделали за вас создатели дистрибутивов и упаковщики. И сделали они это не без веских оснований: например, у замены<strong>init</strong>по причине его слишком инвазивной природы, очень много трудностей и последствий, а справиться со всеми ими весьма сложно вне создания дистрибутива.</p>
12
<p><em>По материалам tproger.ru.</em></p>
12
<p><em>По материалам tproger.ru.</em></p>
13
13