Каковы преимущества использования systemd?

Ubuntu использовала Выскочку начиная с этих 6,10 выпусков. Это было относительно простое и легкое для управления системой и init, который позволил тот интуитивно, и быстро запустите и остановите сервисы по требованию.

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

Какие полезные функции делает systemd обеспечьте, что старая модель Upstart не сделала или не могла обеспечить, что сделал обновление Ubuntu до него?

2
задан 12 August 2016 в 11:24

2 ответа

На самом деле... нет. Как все больше из нас, кто на самом деле ИСПОЛЬЗУЕТ Linux и наблюдает, что железнодорожная авария Potterware разворачивается, мы перемещаемся в systemd свободный disto's.

http://without-systemd.org/wiki/index.php/Main_Page

http://www.gabordemooij.com/index.php?p=/escape_from_systemd

начинающий потока от другого ответа шага и типичен для Microsoft как propoganda в поддержку systemd.

" я думаю, что одна цель состояла в том, чтобы установить единственную init-систему среди всех главных дистрибутивов Linux (они имеют, в настоящее время, более высокую долю рынка: человечность, песни, SuSe) †“knb 12 августа в 7:37"

Это - отношение, которое Вы могли бы ожидать от инженера Microsoft или Apple, это не имеет НИКАКОГО МЕСТА в Linux. Это является раздражающим, чтобы сказать, что это много раз... systemd НЕ является о init... уровень абстракции во многом как это в Windows что сам inposses между Ядром и всем остальным. Это не о запуске Вашей системы... о создании ситуации, куда скоро НИЧТО не будет работать без systemd. Думайте об этом в течение минуты.... Ваша система теперь будет более vulernable, хрупкое.... походит на Linux? Нет...

0
ответ дан 2 December 2019 в 04:54

Этой точкой (который является спустя 3 года после вопроса, отправленный) различные формулировки этого вопроса спросили так много раз, что можно, вероятно, найти намного более подробные и интересные ответы с поисковой системой. Но, именно так этот вопрос имеет фактический ответ, позвольте мне заключить один в кавычки из unix.stackexchange сайта :

И выскочка и systemd являются попытками решить некоторые проблемы с ограничениями традиционной системы SysV init. Например, некоторые сервисы должны запуститься после других служб (например, Вы не можете смонтировать файловые системы NFS, пока сеть не работает), но единственный путь в SysV для обработки, который должен установить ссылки в rc#.d каталоге, таким образом, что каждый перед другим. Добавьте к этому, Вы, возможно, должны были бы перенумеровать все позже, когда зависимости добавляются или изменяются. Upstart и Systemd имеют более интеллектуальные настройки для определения требований. Кроме того, существует проблема с тем, что все - какой-то сценарий оболочки, и не все пишет лучшие init сценарии. Это также влияет на скорость запуска.

Некоторые преимущества systemd I видят:

  • Каждый запущенный процесс получает свой собственный cgroup или конкретный cgroup.
  • Предварительное создание сокетов и дескрипторов файлов для сервисов, подобных тому, как xinetd делает, поскольку это - сервисы, позволяя зависимым сервисам запуститься быстрее. Например, systemd будет содержать открытый дескриптор файла для/dev/log для системного журнала, и последующим сервисам, которые отправляют к/dev/log, буферизуют их сообщения, пока syslogd не будет готов вступить во владение.
  • Меньше процессов, выполненных для фактического запуска сервиса. Это означает, что Вы не пишете сценарий оболочки для запуска сервиса. Это может быть улучшением скорости и (IMO) что-то более легкое для установки во-первых.

Один недостаток, о котором я знаю, - то, что для использования в своих интересах socket/FH предварительного выделения systemd многие демоны должны будут быть исправлены, чтобы передать FH им systemd.

самые большие мифы сообщение в блоге о systemd также имеет эту точку:

  1. Миф: systemd был создан как результат синдрома NIH.

Это не верно. Прежде чем мы начали работать над systemd, мы стремились к Выскочке Canonical, чтобы быть широко принятыми (и Fedora/RHEL использовал его слишком некоторое время). Однако мы в конечном счете пришли к выводу, что его дизайн был по сути испорчен в его ядре (по крайней мере, в наших глазах: наиболее существенно это оставляет управление зависимостью администратору/разработчику, вместо того, чтобы решить эту тяжелую проблему в коде), и если что-то неправильно в ядре, Вы лучше заменяете его, вместо того, чтобы зафиксировать его. Это было едва единственной причиной, хотя, другие вещи, которые сыграли роль, такие как соглашение о лицензировании/вкладе, бездельничают ему. NIH не был одной из причин, хотя..

1
ответ дан 2 December 2019 в 04:54

Другие вопросы по тегам:

Похожие вопросы: