В Ubuntu 15.04 более значительным изменением является переключение с upstart на systemd по умолчанию для управления загрузкой и запуском системного сервиса.
Может ли кто-нибудь адекватно объяснить нетехническому пользователю, как и если это вообще повлияет на нас? И почему это важно?
Ответы:
Пользователи Layman не должны заметить каких-либо изменений, по дизайну. Это система инициализации, а не то, с чем пользователи традиционно взаимодействуют. Он должен полностью заменить функциональность, предоставляемую Upstart, и сделать несколько дополнительных вещей, но единственный раз, когда нетехнический пользователь увидит это, это когда он пойдет не так.
Пользователи, системные администраторы и разработчики, которые активно используют и разрабатывают для Upstart, - это люди, которым нужно что-то решать. В Ubuntu Wiki есть документ по миграции, чтобы помочь разработчикам конвертировать свои сценарии инициализации, но пользователи и системные администраторы могут продолжать использовать Upstart, придерживаясь 14.04 (что поддерживается до 2019 года).
Причина и обоснование изменений действительно были не со стороны Ubuntu. Canonical были достаточно довольны Upstart (их проект), но многие пользователи Debian хотели перейти на современный механизм инициализации, чтобы улучшить параллелизм при загрузке и улучшить функциональность мониторинга во всех сервисах.
Это означало борьбу между различными вариантами (обоснованиями) и systemd.
Canonical пошла вместе с Debian, потому что это самый простой и, вероятно, лучший. Они могут отказаться от проекта и не борются против него. Это также приводит нас в соответствие с другими дистрибутивами (Red Hat, Fedora и т. Д.), Которые также переходят на systemd. Больше внимания и меньше дублирования усилий.
tl; dr Для не технического человека это не должно повлиять на вас вообще. Для Ubuntu это должно означать меньше работы и лучшую систему инициализации.
Может ли кто-нибудь адекватно объяснить нетехническому пользователю, как и если это вообще повлияет на нас?
Теоретически, это не должно влиять на нетехнического конечного пользователя, который не вмешивается в мельчайшие подробности работы системы. На практике вы увидите много вещей.
Вот неполный список:
init5+ rcукушен тем, что systemd только обратно совместим с System 5 rc. Как и выскочка, и, в действительности, большинство других систем, она заявляет и поставляет без обратной совместимости с System 5 initи ее файлом конфигурации /etc/inittab.Таким образом, люди, которые следовали совету 30-летних людей, советующих «Ну, вы можете просто отредактировать это в /etc/inittab…», или люди, которые используют программное обеспечение, которое следовало этому совету, теперь имеют программное обеспечение, которое не запускается при начальной загрузке. Пример: /unix//a/196197/5132
shutdown, как это было с предыдущими shutdownкомандами. Помимо того, что он называется режимом восстановления в жаргоне systemd, режим восстановления не считается состоянием выключения в представлении systemd. Это расценено как работающее государство. shutdown nowвыключит машину. Это systemctl rescueдостижение однопользовательского режима в мире systemd. Дополнительная информация: /unix//a/196471/5132.--userопцией systemctl. Это не относится к Ubuntu (пока). upstart и systemd существенно различаются в этой области, и в Ubuntu версии 15 по-прежнему используется upstart для каждого сеанса, а не systemd для каждого пользователя . Так, например, /superuser//a/860598/38062 не будет применяться. ☺Как уже отмечали другие, теоретически, это не должно влиять на конечного пользователя, не являющегося техническим специалистом, - и в теории нет разницы между теорией и практикой, но на практике есть.
Я думаю, что несколько вещей, размещенных здесь, нуждаются в пояснениях:
Это система инициализации, а не то, с чем пользователи традиционно взаимодействуют.
Это было в случае с SysV init и Upstart, но это больше не относится к systemd. Он делает много вещей, с которыми пользователи традиционно взаимодействуют:
Он должен полностью заменить функциональность, предоставляемую Upstart, и сделать несколько дополнительных вещей
Две вещи, которые нужно уточнить - сначала о полной замене Upstart:
Одна из проблем, с которой сталкиваются люди с systemd, заключается в том, что он не запускает сценарии инициализации SysV. Так что есть один пример, который не полностью заменяет функциональность, предоставляемую Upstart.
Это то, на что мы могли положиться более 30 лет, и традиционно вы писали сценарии инициализации SysV для максимальной переносимости, не повторяя себя (написав несколько версий одних и тех же сценариев), что уже не так.
Это не должно быть проблемой при использовании только пакетов из официальных репозиториев, потому что, вероятно, для всех пакетов, в которых раньше использовались сценарии SysV init или Upstart, необходимо было бы переписать свои сценарии, прежде чем они будут упакованы.
Это будет проблемой только для тех, кто использует любое стороннее или пользовательское программное обеспечение, для которого сценарии инициализации написаны либо для SysV init, либо для Upstart, и им потребуется переписать сценарии инициализации перед обновлением до системы с помощью systemd (или получить установленный upstart, который также является опцией , или перейдите на систему, которая не использует systemd).
Существует systemd-sysv-generator, который должен автоматически переводить сценарии инициализации SysV в сценарии systemd, но есть некоторые ошибки и длинный список явных несовместимостей .
Теперь второе уточнение - о тех немногих лишних вещах:
Те «несколько дополнительных вещей», которые собирается охватить systemd - в соответствии с «Перспективой для systemd - Что было достигнуто» и «Что ждет впереди » Леннарта Поеттеринга в 2014 году на GNOME.asia - следующие:
Итак, вернемся к: «Это система инициализации, а не то, с чем пользователи традиционно взаимодействуют». - следует отметить, что система инициализации - это всего лишь один элемент в этом списке.
И, наконец, последнее, что я хотел бы прокомментировать:
[T] он только раз, когда нетехнический пользователь увидит это, когда это пойдет не так.
О, какое облегчение. :)
Наиболее заметные изменения для конечных пользователей (кроме самих сценариев) - запуск и остановка служб и использование таких команд, как:
который больше не работает, как ожидалось. Например, nohupэто команда POSIX, чтобы убедиться, что процесс продолжает работать после выхода из сеанса. Это больше не работает на systemd. Кроме того, такие программы, как screenи tmuxдолжны вызываться особым образом, иначе процессы, которые вы запускаете с ними, будут убиты (хотя не уничтожение этих процессов обычно является основной причиной запуска screen или tmux в первую очередь).
Это не ошибка, это выбор дизайна, поэтому он вряд ли будет исправлен в будущем. Вот что Леннарт Поеттеринг сказал по этому поводу:
На мой взгляд, в UNIX было довольно странно, что по умолчанию произвольный пользовательский код оставался неограниченным после выхода из системы. Многие люди, работающие с ОС, уже давно обсуждают, что это должно быть возможно, но, конечно, не по умолчанию, но никто так и не осмелился щелкнуть переключателем, чтобы превратить его из значения по умолчанию в опцию. Не очистка пользовательских сессий после выхода из системы - это не только уродливо и несколько хакерски, но и проблема безопасности. Теперь systemd 230 наконец-то щелкнул переключателем и, наконец, по умолчанию все корректно очищает, когда пользователь выходит из системы.
Для получения дополнительной информации см .:
screenscreensystemd-run --user --scope screen(Примечание: поведение "upstart" выше действительно что-то кроме systemd, это не специфично для upstart)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(См. Мой ответ на Каковы плюсы / минусы Upstart и systemd? Для более подробной информации, которая выходит за рамки этого вопроса.)
Существует также большая разница в обработке журналов, поскольку в отличие от традиции Unix журналы systemd хранятся в двоичных файлах в произвольном формате, поэтому вместо:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
вам нужно использовать специальные команды для доступа к вашим журналам:
sudo journalctl -u foo
sudo journalctl -u foo -f
Внедрение systemd сначала в Debian, а затем в Ubuntu не обошлось без противоречий и широкого противостояния, как известно любому, кто написал одну из следующих статей:
Официальная позиция Debian на Systemd и в результате полемика привела к декларации Исх в 2014 году и закончилась отставкой Яна Джексона .
Инициативы Инициативы Freedom , Without-Systemd.org и Systemd-Free.org были рождены, и многие обсуждали Hacker News .