Вопросы Теги

Каковы профессионалы/недостатки Выскочки и systemd?

Если Вы не имеете sort -h можно сделать это:

du -sh * | sed 's/\([[:digit:]]\)\t/\1B\t/' | sed 's/\(.\t\)/\t\1/' | sed 's/G\t/Z\t/' | sort -n -k 2d,2 -k 1n,1 | sed 's/Z\t/G\t/'

Это получает список du, разделяет суффикс и виды с помощью этого. С тех пор нет никакого суффикса для <1K, первый sed добавляет B (для байта). Второй sed добавляет разделитель между цифрой и суффиксом. Третий sed преобразовывает G в Z так, чтобы это было больше, чем M; если у Вас есть файлы терабайта, необходимо будет преобразовать G в Y и T к Z. Наконец, мы сортируем по двум столбцам, затем мы заменяем суффикс G.

184
24.02.2011, 16:55
6 ответов

Обновление 2016 года

Большинство ответов здесь пятилетней давности, так что пришло время для некоторых обновлений.

Ubuntu использовала upstart по умолчанию, но в прошлом году они отказались от него в пользу systemd - смотрите:

В связи с этим на Ubuntu wiki есть хорошая статья Systemd for Upstart Users - очень подробное сравнение между upstart и systemd и руководство по переходу с upstart на systemd.

(Обратите внимание, что согласно Ubuntu wiki вы все еще можете запустить upstart на текущих версиях Ubuntu по умолчанию, установив upstart-sysv и выполнив sudo update-initramfs -u, но учитывая масштаб проекта systemd, я не знаю, как это работает на практике, и можно ли удалить systemd. )

Большая часть информации в разделах Commands и Scripts ниже адаптирована из некоторых примеров, использованных в этой статье (которая удобно лицензирована, как и материалы пользователей Stack Exchange, по лицензии Creative Commons Attribution-ShareAlike 3.0 License).

Вот краткое сравнение обычных команд и простых скриптов, подробное объяснение смотрите в разделах ниже. В этом ответе сравнивается старое поведение систем на базе Upstart с новым поведением систем на базе systemd, как было задано в вопросе, но обратите внимание, что команды, помеченные как "Upstart", не обязательно специфичны для Upstart - это часто команды, общие для всех Linux и Unix систем без systemd.

Команды

Выполнение su:

  • upstart: su
  • systemd: machinectl shell

(см. раздел "Замена команды su" ниже)

Выполнение screen:

  • upstart: screen
  • systemd: systemd-run --user --scope screen

(см. раздел "Неожиданное убийство фоновых процессов" ниже)

Запуск tmux:

  • upstart: tmux
  • systemd: systemd-run --user --scope tmux

(см. раздел "Неожиданное убийство фоновых процессов" ниже)

Запуск job foo:

  • upstart: start foo
  • systemd: systemctl start foo

Stopping job foo:

  • upstart: stop foo
  • systemd: systemctl stop foo

Restarting job foo:

  • upstart: restart foo
  • systemd: systemctl restart foo

Перечисление заданий:

  • upstart: initctl list
  • systemd: systemctl status

Проверка конфигурации задания foo:

  • upstart: init-checkconf /etc/init/foo. conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo. service

Список переменных окружения задания:

  • upstart: initctl list-env
  • systemd: systemctl show-environment

Установка переменной окружения задания:

  • upstart: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Удаление переменной окружения задания:

  • upstart: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Журналы

В upstart журналы являются обычными текстовыми файлами в каталоге /var/log/upstart, поэтому вы можете обрабатывать их как обычно: 

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

В systemd журналы хранятся во внутреннем двоичном формате (не как текстовые файлы), поэтому для доступа к ним нужно использовать команду journalctl:

sudo journalctl -u foo
sudo journalctl -u foo -f

Скрипты

Пример скрипта upstart, написанного в /etc/init/foo. conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Пример systemd скрипт, написанный в /lib/systemd/system/foo. service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

замена команды su

Замена команды su была включена в systemd в pull request #1022:

потому что, по словам Леннарта Поттеринга, "su - это действительно сломанная концепция".

Он объясняет, что "вы можете использовать su и sudo как раньше, но не ожидайте, что они будут работать в полном объеме".

Официальный способ достижения su-подобного поведения теперь такой:

machinectl shell

Это было дополнительно объяснено Леннартом Поттерингом в обсуждении к выпуску #825:

"Ну, об этом долго говорили, но проблема в том. что то, что должен делать su, очень неясно. [...] Короче говоря: su - это действительно сломанная концепция. Она дает вам что-то вроде оболочки, и это нормально, если использовать его для этого, но это не полноценный логин, и не следует принимать его за таковой". - Lennart Poettering

См. также:

Неожиданное завершение фоновых процессов

Команды типа:

больше не работают так, как ожидалось. Например, nohup - это команда POSIX для обеспечения того, чтобы процесс продолжал работать после выхода из сеанса. Она больше не работает в systemd. Также такие программы как screen и tmux должны вызываться особым образом, иначе процессы, которые вы запускаете вместе с ними, будут убиты (в то время как не убивать эти процессы обычно является основной причиной запуска screen или tmux в первую очередь).

Это не ошибка, это преднамеренное решение, поэтому вряд ли оно будет исправлено в будущем. Вот что Леннарт Поттеринг сказал по этому поводу:

На мой взгляд, это было довольно странно для UNIX, что он по умолчанию позволял произвольному пользовательскому коду неограниченно оставаться после выхода из системы. Многие люди, работающие с ОС, уже давно обсуждают, что это возможно, но, конечно, не должно быть по умолчанию, но никто до сих пор не осмелился щелкнуть переключателем, чтобы превратить это из умолчания в опцию. Не очищать сессии пользователя после выхода из системы - это не только некрасиво и несколько по-хакерски, но и проблема безопасности. systemd 230 наконец-то переключился и по умолчанию корректно очищает все сеансы после выхода пользователя из системы.

Подробнее см.:

Высокоуровневая концепция запуска

В некотором смысле systemd работает в обратном направлении - В upstart задания запускаются, как только могут, а в systemd - когда должны. В конце дня одни и те же задания могут быть запущены обеими системами и практически в одном и том же порядке, но вы думаете об этом, глядя, так сказать, с противоположного направления.

Вот как Systemd для пользователей Upstart объясняет это:

Модель Upstart для запуска процессов (заданий) является "жадной событийной", т.е. все доступные задания, события запуска которых произошли, запускаются запускаются как можно раньше. Во время загрузки upstart синтезирует некоторые начальные события, такие как startup или rcS, в качестве "корня дерева", ранние службы запускаются по ним, а более поздние службы запускаются, когда первые запущены. Новое задание просто должно установить свой конфигурационный файл в /etc/init/, чтобы стать активным. Модель

systemd для запуска процессов (юнитов) является "ленивой зависимостью", т.е. юнит запускается только тогда, когда от него зависит какой-то другой юнит. зависит от него. Во время загрузки systemd запускает "корневой модуль" (default.target, может быть переопределен в grub), который затем транзитно расширяется и запускает свои зависимости. Новый блок должен добавить себя в качестве зависимость от какого-либо блока последовательности загрузки (обычно multi-user.target), чтобы стать активным.

Использование в дистрибутивах

Теперь некоторые свежие данные согласно Википедии:

Дистрибутивы, использующие upstart по умолчанию:

Дистрибутивы, использующие systemd по умолчанию:

(см. Wikipedia для получения актуальной информации)

Дистрибутивы, не использующие ни Upstart, ни systemd:

Споры

В прошлом был предложен форк Debian, чтобы избежать systemd. Был создан Devuan GNU+Linux - форк Debian без systemd (спасибо fpmurphy1 за указание на это в комментариях).

Более подробную информацию об этом споре смотрите:

Как многие из вас, возможно, уже знают, голосование по Init GR Debian, которое продвигал Иэном Джексоном, не помогло защитить наследие Debian и его пользователей от лавины systemd.

Эта ситуация создает перспективы блокировки зависимостей systemd, которая де-факто угрожает свободе разработки и имеет серьёзные последствия для Debian, его upstream и downstream.

CTTE удалось поменять местами зависимости и выиграть время из-за тонкой установки systemd вместо sysvinit, но даже этот процесс был изнурительным и полным драматизма. В конце концов, неделю назад Иэн Джексон подал в отставку. [...]

Я выхожу из состава Технического комитета с немедленным вступлением в силу.

Хотя важно, чтобы мнение 30-40% участников проекта, которые согласны со мной, должны быть представлены в ТК, я сам являюсь очевидно, слишком противоречивая фигура на данном этапе, чтобы делать это. Мне следует отойти в сторону, чтобы попытаться уменьшить степень, до которой разговоры о управления проектом переходят на личности. [...]

Devuan родился в результате споров о решении использовать в качестве системы init по умолчанию в Debian. Официальная позиция Debian по поводу systemd полна утверждений, которые другие развенчали. Заинтересованные Читатели могут продолжить обсуждение этой горячей темы в The systemd controversy. Однако мы призываем вас сохранять холодный ум и голос вежливым. В Devuan мы больше заинтересованы в том, чтобы программировать неправильно чем оглядываться назад. [...]

Создано несколько сайтов и статей, посвященных спорам о systemd:

Есть много интересных обсуждений на Hacker News:

Подобные тенденции можно наблюдать и в других дистрибутивах:

Philosophy

upstart следует философии Unix - DOTADIW - "Do One Thing and Do It Well". Это замена традиционного демона init. Он не делает ничего, кроме запуска и остановки служб. Другие задачи делегируются другим специализированным подсистемам.

systemd делает гораздо больше. В дополнение к запуску и остановке служб она также управляет паролями, входами в систему, терминалами, управлением питанием, сбросом заводских настроек, обработкой журналов, точками монтирования файловой системы, сетевым взаимодействием и многим другим - о некоторых возможностях см. файл NEWS.

Планы по расширению

Согласно Перспектива для systemd Что было достигнуто, и что ждет впереди презентация Леннарта Поттеринга в 2014 году на GNOME.asia, вот основные цели systemd, области, которые уже охвачены, и те, которые еще в процессе:

цели systemd:

Наши цели

  • Превращение Linux из мешка с битами в конкурентоспособную операционную систему общего назначения.
  • Создание ОС нового поколения для Интернета Устранение бессмысленных различий между дистрибутивами

  • Возвращение инноваций в ядро ОС

  • Настольная, серверная, контейнерная, встраиваемая, мобильная, облачная, кластерная, ... . Эти области ближе друг к другу, чем вы думаете

  • Снижение сложности администратора, надежность без надзора
  • Все интроспективно
  • Автоматическое обнаружение, plug and play - ключ
  • Мы чиним вещи там, где они сломаны, никогда не заклеиваем их

Области, которые уже охвачены:

Что мы уже охватили:

Система init, ведение журнала, управление логинами, управление устройствами, управление временными и изменчивыми файлами, регистрация двоичных форматов, сохранение/восстановление подсветки, сохранение/восстановление rfkill, bootchart, readahead, настройка зашифрованного хранилища, обнаружение разделов EFI/GPT, регистрация виртуальной регистрация виртуальных машин/контейнеров, управление минимальными контейнерами, имя хоста управление, управление локалями, управление временем, управление случайными семенами управление, управление переменными sysctl, управление консолью, ....

Текущая работа:

Над чем мы работаем:

  • управление сетью
  • systemd-networkd
  • локальный кэш DNS, mDNS responder, LLMNR responder, DNSSEC verification
  • IPC в ядре
  • kdbus, sd-bus
  • Синхронизация времени с NTP
  • systemd-timesyncd
  • Больше интеграции с контейнерами
  • Sandboxing of Services
  • Sandboxing of Apps
  • Формат образа ОС
  • Формат образа контейнера
  • Формат образа приложения
  • GPT с автообнаружением
  • Stateless systems, instantiatable systems, сброс к заводским настройкам
  • /usr - ОС
  • /etc - (необязательно) конфигурация
  • /var - (необязательно) состояние
  • Атомарная инициализация и обновления узлов
  • Интеграция с облаком
  • Управление сервисами на узлах
  • Верифицируемые образы ОС
  • Весь путь до прошивки
  • Boot Loading

Область применения этого ответа

Как отметил fpmurphy1 в комментариях, "Следует отметить, что systemd с годами расширил сферу своей работы далеко за пределы простого запуска системы. "

Я постарался включить сюда большую часть релевантной информации. Здесь я сравниваю общие возможности Upstart и systemd при использовании их в качестве систем init, как было задано в вопросе, и я упоминаю только те возможности systemd, которые выходят за рамки системы init, потому что их нельзя сравнивать со Startup, но их наличие важно для понимания разницы между этими двумя проектами. Для получения дополнительной информации следует обратиться к соответствующей документации.

Дополнительная информация

Дополнительную информацию можно найти на:

Дополнительно

Команда LinOxide создала Systemd vs SysV Init Linux Cheatsheet.

90
27.01.2020, 19:28

И выскочка и 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.

68
27.01.2020, 19:28
  • 1
    PulseAudio является очень порочившей аудиосистемой (pulseaudio.org), первоначально записанный Lennart Poettering, автором systemd. Я главным образом подшучивал здесь, потому что я знаю несколько человек, которым нравится жаловаться на pulseaudio, и я уверен, что они жаловались бы на systemd также. Честно, у меня не было проблемы или с systemd или с pulseaudio. –  jsbillings 20.01.2011, 19:48
  • 2
    Делает тот почти сосной для богатых фьордов Plan9... все - файл. –  dhchdhd 11.05.2011, 12:29
  • 3
    Честно говоря, pulseaudio был решением несуществующей проблемы. Нет ничего, что PA может сделать это, ALSA не может, и я услышал МНОГО людей, имеющих проблемы с PA, много раз. –  WhyNotHugo 23.07.2012, 07:37
  • 4
    Двум systemd недостаткам Вы пропустили: (1) все сценарии запуска должны быть переписаны. (2) существует путь меньше совместимости с OSs не-Linux (как BSDs, например). –  WhyNotHugo 23.07.2012, 07:38
  • 5
    Просто большой. Смотрите на 0pointer.de/blog/projects/the-biggest-myths. Я засвидетельствовал рост systemd и могу засвидетельствовать, что так большая часть критических замечаний, данных здесь, абсолютно необоснованна. В ссылке Вы найдете удар ударом, обоснованным опровержением. –  vonbrand 28.01.2013, 00:45

Видел systemd упомянутый на Дуге Общий ML сегодня. Таким образом читайте на нем. H Онлайн как всегда является большим источником для Технологии Linux и - где я нашел, что мое место начало исследовать Systemd как Новомодную альтернативу и SysV Init. Однако статья H Online (в этом случае) не является очень полезным чтением, реальное использование позади нее - она, дает ссылки на полезные чтения.

Реальный ответ находится в объявлении о systemd. Который дает несколько критических моментов что случилось с SysV initd, и что должны сделать новые системы

  • Запускаться меньше.
  • И запускаться больше параллельно.

Его главный план сделать это, кажется, для запуска сервисов только, поскольку они необходимы, и запускать сокет для того сервиса, так, чтобы сервис, для которого нужен он, мог соединиться с созданным сокетом задолго до того, как демон полностью онлайн. По-видимому, сокет сохранит небольшое количество буферизированных данных, означающих, что никакие данные не будут потеряны во время задержки, это будет обработано, как только демон онлайн.

Другая часть плана, кажется, чтобы не сериализировать файловые системы, но вместо этого смонтировать их по требованию также, тот способ, которым Вы не ожидаете на Вашем /home/, и т.д. (чтобы не быть перепутанным с /etc) смонтироваться, и/или fsck когда Вы могли запускать демонов как / и /var/ и т.д., уже смонтированы. Это сказало, что собиралось использовать autofs с этой целью.

Это также имеет цель создания .desktop разработайте init дескрипторы как замену для сценариев. Это предотвратит тонны медленных sh процессы и еще больше ветвлений процессов от вещей как sed и grep это часто используется в сценариях оболочки.

Они также планируют не запустить некоторые сервисы, пока относительно них не просят и возможно даже отключают их, если они больше не необходимы, модуль Bluetooth, и демон только необходим, когда Вы используете bluetooth-устройство, например. Другим данным примером является ssh демон. Это - вид вещи, к которой inetd способен. Лично я не уверен, что мне нравится это, поскольку это могло бы означать задержку, когда мне действительно нужны они, и в случае ssh я думаю, что это означает возможную уязвимость системы обеспечения безопасности, если бы мои inetd были поставлены под угрозу, то целая система была бы. Однако мне сообщили, что с помощью этого для нарушения этой системы неосуществимо и что, если я хочу, я могу отключить эту опцию на сервис и другими способами.

Другая функция, по-видимому, будет возможностью запуститься на основе событий времени, или в регулярно запланированном интервале или в определенное время. Это подобно какой crond и atd сделайте теперь. Хотя мне сказали, что это не будет поддерживать пользователя "крон". Лично это походит на самую бессмысленную вещь. Я думаю, что это писалось/думалось людьми, которые не работают в пользовательских средах, нет большой цели к пользовательскому крону, если Вы - единственный пользователь в системе кроме не выполнения как корень. Я ежедневно работаю над многопользовательскими системами, и правило всегда является запускаемыми пользовательскими скриптами как пользователем. Но возможно у меня нет предвидения, которое они делают, и оно никоим образом не сделает его так, чтобы я не мог работать crond или atd, таким образом, никому, но разработчикам не причиняет боль, что я предполагаю.

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

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

Или помещать его более простой: то, что пользователь только что запустил D-шину, никоим образом не является признаком, что NetworkManager должен быть запущен также (но это - то, что Выскочка сделала бы). Это правильно наоборот: когда пользователь просит NetworkManager, который является определенно признаком, что D-шина должна быть запущена также (который является, конечно, что большинство пользователей ожидало бы, правильно?).
Хорошая init система должна запустить только, что необходимо, и что по запросу. Или лениво или параллелизированный и заранее. Однако это не должно запускаться более, чем необходимый, особенно не все установило, который мог использовать тот сервис.

Поскольку я уже сказал, что это обсуждено намного более всесторонне в объявлении о systemd.

29
27.01.2020, 19:28
  • 1
    извините, но объявление похож на книгу. Я должен читать и grok, прежде чем я смогу действительно включать больше здесь. –  xenoterracide 20.01.2011, 17:56
  • 2
    , Как это лучше, чем ответ @John? Действительно ли это - заполнитель? Объявление H Онлайн? –  tshepang 20.01.2011, 19:46
  • 3
    @tshepang хорошо, который это на самом деле связывает с объявлением о системе d и h материал онлайн, имеет ссылки на это и другие интересные ссылки. это - долгое утомительное чтение. Я мог бы добавить больше, после того как у меня есть groked это... это не простой предмет. когда я записал это, я полагал, что Вы могли бы хотеть начать читать раньше, чем позже. но не стесняйтесь к модификации меня вниз. конечно, ответ @jsbillings достоин, и лучше, чем мой до сих пор. но не столь хороший как чтение самого объявления –  xenoterracide 20.01.2011, 20:03
  • 4
    @tshepang я, вероятно, добавлю больше завтра после кровати. h материал онлайн был просто я являющийся хорошим журналистом и цитирующий мои источники. –  xenoterracide 20.01.2011, 20:05
  • 5
    @tshepang. Я обновил свой ответ. вполне уверенный я сделан, если услужливые люди на irc://frenode.net/systemd не решают, что хотят предложить исправление некоторого вида. –  xenoterracide 21.01.2011, 21:20

Хорошо одной вещью, которую забыло большинство из Вас, является организация процессов в cgroups.

Таким образом, если systemd запустил вещь, он вставит эту вещь ее собственный cgroup и нет никакого (unpriviledged), средний для процесса для выхода из этого cgroup. Вот последствия этого:

  • У администратора большой системы со многими пользователями есть эффективные новые способы идентифицировать злонамеренных пользователей/процессы.
  • Приоритеты для планирования ЦП могут быть определены лучше, как сделано "Удивлением autocgroup патч".
11
27.01.2020, 19:28

Для очень подробного взгляда systemd, начиная с первых проектов дизайна (и подробный критический анализ существующих init систем, включая выскочку, и как systemd предлагает зафиксировать их), перейдите к его домашней странице. Со временем было несколько статей о запуске, опубликованном в LWN. Просто сообщите, что любое упоминание о systemd (или pulseaudio) там инициировало бесконечный flamewars.

IMVHO (и как пользователь Fedora) я очень доволен им. Что-то в этой строке давно ожидалось для обработки сложности существующих систем Linux. Fedora использовала выскочку некоторое время, но это никогда не выходило из этапа того, чтобы быть необычной заменой для sysvinit, запуская главным образом неизменные init скрипты. Его обещание упрощения загрузочной конфигурации происходит за счет снова ручной установки взаимозависимостей, и это просто не работает. systemd понимает dependecies отдельно (или просто позволяет запускать материал без учета зависимостей, они разбираются). Другим большим преимуществом (некоторые говорят это, является серьезный недостаток), то, что это использует определенные для Linux функции к рукоятке (особенно cgroups, позволяют изолировать демона и всех ее потомков, таким образом, легко контролировать, ограничить ресурсы или уничтожить их как группу; существуют многие другие).

8
27.01.2020, 19:28

Журналирование - Systemd буквально похожа на папку WinSXS, когда дело доходит до журналирования, он создает копии копий, если вы вручную не удалите или не уменьшите размер файла, он будет продолжать разъедать ваш диск. Я называю это куки загрузчика.

3
27.01.2020, 19:28

Теги

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