LINUX.ORG.RU

Альтернатив systemd тред

 , ,


0

4

В общем думаю поменять systemd на что-то более простое, с KISS и ламповыми текстовыми логами. Очень не хочется проигрывать в надёжности системы. Есть arch, awesome wm. Одна из фич systemd - быстрый запуск системы не принципиален ибо система у меня перезагружается 2-3 раза в полгода, когда не нужна отправляется в сон.

Ещё интересно какие могут быть подводные камни такой подпольной жизни посреди «мира systemd».

PS да и ещё желательно поменять на что-то более лёгкое, ато прилагающийся к systemd утиль довольно жруч.

★★★★★

Последнее исправление: ados (всего исправлений: 1)

Да никаких камней - если твоему софту systemd не нужен то ты можешь его не использовать.

не хочется проигрывать в надёжности системы
arch
перезагружается 2-3 раза в полгода

Тут что-то лишнее, я никак не могу понять что...

alozovskoy ★★★★★
()
Ответ на: комментарий от alozovskoy

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

ados ★★★★★
() автор топика
Последнее исправление: ados (всего исправлений: 1)

не хочется проигрывать в надёжности системы

хочу поменять один из самых важных компонентов дистрибутива на самоделку

Вперёд и с песней.

intelfx ★★★★★
()

Из простого — runit. На Void как раз используется. Работает довольно шустро и без каких-либо видимых проблем. В качестве тупой запускалки процессов и демонов вполне сойдёт.

kachsheev ★★★
()

Использую sysvinit, ни одна скотина ещё не жаловалась, хотя из-за гнома и загадочного Debian установлен пакет systemd (используется systemd-logind), но не используется в качестве init. С systemd наигрался в своё время, не хочу его, хочу syslog и простые скрипты в /etc/init.d и не парится.

slapin ★★★★★
()

systemd — мэйнстрим. Это значит, что программы будут затачиваться под взаимодействие с системд.
Значит, если не хочется геморроя в будущем, это должно быть что-то системд-совместимое.

Bad_ptr ★★★★★
()

Мелкомягкие своего добились. Выросло поколение, которое ищет альтернативы systemd, а ведь на самом деле это systemd альтернатива нормальным инитам.

Lavos ★★★★★
()

Из нормальных альтернатив есть SMF. С большой натяжкой - upstart, launchd. На линуксе из перечисленного только никому не нужный upstart.

anonymous
()

У меня везде (и дома, и на работе, и на VPS-ках) используется OpenRC

XMs ★★★★★
()

Одна из фич systemd - быстрый запуск системы

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

Falcon-peregrinus ★★★★★
()

очевидная слака. особенно вот-вот 14.2 должны выпустить.

Avial ★★★★★
()

смотря что именно тебе надо, в manjaro или как там его есть вариант с openrc, если не хочется самому копаться. Есть s6, runit и т.п. Просто удостоверься что софту не нужно половина system и используй.

qnikst ★★★★★
()

На раче пробовал openrc, официальной поддержки нет, так что если нужна стабильность, и чтобы «всё работало», то лучше остаться на systemd.

sudopacman ★★★★★
()

Если нужен KISS - тащи инициализацию из слаки. Проще, надёжнее и быстрее не придумаешь.

ЗЫ: слухи о быстроте загрузки системы с systemd сильно преувеличены.

Stanson ★★★★★
()
Ответ на: комментарий от Bad_ptr

systemd — мэйнстрим. Это значит, что программы будут затачиваться под взаимодействие с системд.

Иди читни реймондцаESRца :) Быдлокодеры да, прибивают программы гвоздями к чему-то.

если не хочется геморроя в будущем

это должно быть что-то системд-совместимое.

Noep. «Этому» должно быть фиолетово, есть системд или нет :) Оно может им пользоваться если есть. Но от его отсутствия не должно впадать ни в панику, ни в корку.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 2)

использую старые sysvinit в арче. проблем нет, брат жив.

val-amart ★★★★★
()
Ответ на: комментарий от Falcon-peregrinus
 # >  systemd-analyze
Startup finished in 12.463s (firmware) + 12ms (loader) + 1.121s (kernel) + 2.418s (userspace) = 16.015s

В человекочитаемом виде:

 # >  /mnt/userdata/work/bin/startup
===== STARTUP =====

  firmware:   12.463s
  loader:     12ms
  kernel:     1.121s
  userspace:  2.418s
  total:      3.552s (16.015s)

Unit files. E:13; D:36.
  @912ms	+5ms	 - systemd-logind.service
  @879ms	+1ms	 - systemd-update-done.service
  @357ms	+59ms	 - ldconfig.service
  @101ms	+4ms	 - systemd-tmpfiles-setup-dev.service
  @97ms	+3ms	 - systemd-sysusers.service
  @91ms	+5ms	 - systemd-remount-fs.service
  @76ms	+13ms	 - systemd-fsck-root.service

===================
И это после внезапного отключения электроэнергии.

Так что тут или у тебя это на религиозной почве, или ты просто не хочешь учиться его готовить.

r3lgar ★★★★★
()
Ответ на: комментарий от sudopacman

Не надо чушь городить, ладно? Дело не в профиле, а в софте, который умеет только в logind и компанию. Это не проблема генты, а проблема кривых рук. Я жил на OpenRC, и не видел ничего из systemd в своей системе, теперь живу на systemd, и не вижу ничего от OpenRC.

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

Дюже прытко, у меня вот так:
$ systemd-analyze
Startup finished in 5.750s (kernel) + 1min 7.520s (userspace) = 1min 13.271s
Кеды вместо окружения рабочего стола, Debian 8 вместо операционной системы, SSD вместо диска с корнем.

Exmor_RS ★★★
()
Ответ на: комментарий от r3lgar

Эээ. Какая проблема генты? Я говорил вообще говорил про то, что рач с опенрц из сторонних реп — как гента с опенрц, но в которой все пакеты собраны как если бы у тебя был сустемд (в генте такое, правда, невозможно, потому что из-за юзов systemd прилетит как зависимость, и с openrc то же самое, но в общем суть примерно понятна)

sudopacman ★★★★★
()
Ответ на: комментарий от sudopacman

Ладно, раскрою секрет:

$ systemd-analyze critical-chain 
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 7.497s
└─multi-user.target @1min 7.497s
  └─ntp.service @17.403s +50.093s
    └─basic.target @17.177s
      └─paths.target @17.148s
        └─cups.path @17.148s
          └─sysinit.target @17.141s
            └─nfs-common.service @17.057s +83ms
              └─rpcbind.target @17.057s
                └─rpcbind.service @17.026s +30ms
                  └─network-online.target @17.026s
                    └─network.target @17.026s
                      └─ifup@eth1.service @17.025s
                        └─networking.service @1.736s +15.273s
                          └─bootcdflop.service @1.726s +8ms
                            └─local-fs.target @1.709s
                              └─run-rpc_pipefs.mount @17.135s
                                └─local-fs-pre.target @487ms
                                  └─systemd-remount-fs.service @469ms +17ms
                                    └─keyboard-setup.service @198ms +259ms
                                      └─systemd-udevd.service @192ms +4ms
                                        └─systemd-tmpfiles-setup-dev.service @160ms +31ms
                                          └─kmod-static-nodes.service @149ms +10ms
                                            └─system.slice @130ms
                                              └─-.slice @130ms

Exmor_RS ★★★
()
<de_graf> у меня OpenRC
<guybo> Да я вспомнил
<de_graf> прекрасно себя чувствую
<guybo> Да я тоже не страдаю
<de_graf> ты такой раздражительный. Это из-за бинарных логов
i-rinat ★★★★★
()
Ответ на: комментарий от sudopacman

Оно что-то своё показывает. У меня systemd-analyze вообще больше двух минут пишет. Тоже на SSD. При этом до графического приглашения грузится 6 секунд ровно по секундомеру.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Не знаю, у меня всё правильно показывало (ну, правда, оно не учитывает врмя запуска приложений после логина пользователя в tty)

sudopacman ★★★★★
()
Ответ на: комментарий от Exmor_RS

Вообще, у меня 600-900 ms на нормальном запуске (я не считаю время firmware, так как это наглый 3.14-здёж, система грузится от силы секунды две от нажатия кнопки запуска до предложения ввода пароля), но у меня вместо загрузчика — UEFI, вместо диска — SSD, вместо дистра — Gentoo, вместо всего остального причёсанный софт, не прибитый ни к чему гвоздями. Да и большинство service-файлов подправлены, и таргеты тоже причёсаны, и всё лишнее отключено (но не замаскировано). Я не задавался целью быстро грузиться, так как комп ходит в ребут только при обновлении ядра, и то через раз, в остальное время он у меня даже не ходит в сон.

r3lgar ★★★★★
()
Ответ на: комментарий от sudopacman

из-за юзов systemd прилетит как зависимость, и с openrc то же самое

Даже без юзов некоторый софт требует systemd, ибо завязан на. И гента немного прибита к OpenRC из-за gentoo-functions, но второе решается установкой отдельного пакета вместо всего openrc, а вот с первым немного беда.

To @all: Вообще, не понимаю бугурта по поводу инита, ни со стороны ярых противников systemd, ни со стороны его ярых поклонников. Это просто инструмент. Нравится концепция, осилил документацию — пользуйся, нет — пользуйся чем-то другим, благо альтернативы всегда имеются. Повод бугуртить за эти годы так и не раскрыт, а срачи на ЛОРе продолжаются.

r3lgar ★★★★★
()
Ответ на: комментарий от sudopacman

1min 13.271s
SSD

Каааааааааааааааааааааааааааааак?

Как я и догадывался, его система ждёт доступности сети, а это 15-60 секунд обычно.

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

To @all: Вообще, не понимаю бугурта по поводу инита, ни со стороны ярых противников systemd, ни со стороны его ярых поклонников. Это просто инструмент. Нравится концепция, осилил документацию — пользуйся, нет — пользуйся чем-то другим, благо альтернативы всегда имеются. Повод бугуртить за эти годы так и не раскрыт, а срачи на ЛОРе продолжаются.

Лично я несколько недолюбливаю systemd по одной простой причине. Его добровольно-принудительно притащили в некоторые из используемых мной дистрибутивы, заменили то, что прекрасно работало и не дали ни одной новой полезной функции. Проще говоря, мне пришлось в силу профессии тратить время на изучение нового инструмента, который по сути мне не нужен, так как старый был не хуже и со всеми задачами справлялся отлично. Может быть когда-нибудь мне понадобится что-то из функционала systemd, но я считаю, что именно тогда и стоит осознанно его ставить и изучать. Поэтому дома на десктопах у меня gentoo, openrc и eudev. А вот на серверах debian и systemd.

shell-script ★★★★★
()
Ответ на: комментарий от shell-script

Его добровольно-принудительно притащили в некоторые из используемых мной дистрибутивы, заменили то, что прекрасно работало

Причём работало годами и жрать не просило. Тут да, согласен, но это камень в огород не systemd, а манагерам дистра, так что аргумент засчитан лишь наполовину. (=

r3lgar ★★★★★
()
Ответ на: комментарий от shell-script

А вот на серверах ... и systemd.

Каскадёр ? :-) Ухожу, ухожу...

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от r3lgar

И что? А DHCP сервер, например, тупит. Или там mariadb/postgres c кластером синкаются минут 10. И сколько ты будешь ждать реальной готовности системы к работе? Эти говноциферки вообще ни о чём не говорят, с таким же успехом можно тупо запустить всё скопом, с & из единственного скрипта, вообще без всякой системы инициализации и получить промпт шелла раз в 5 быстрее чем вот это вот идиотское позорище. Толку-то от этого.

Это та же херня что и с виндой - раз-два и уже десктоп. А работать один хер невозможно ещё пару минут..

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

с таким же успехом можно тупо запустить всё скопом, с & из единственного скрипта

Про зависимости не в курсе, да?

А работать один хер невозможно ещё пару минут.

Что за калькулятор вместо компа?

Radjah ★★★★★
()
Ответ на: комментарий от Radjah

Про зависимости не в курсе, да?

Их важность тоже сильно преувеличена. Если демоны не цепляются к конкретным интерфесам и ИП, например, а слушают на 0.0.0.0 - то им по барабану, поднялся ли какой-нибудь eth8 при запуске или ещё нет. Лишь бы хотя бы один lo был - всё будет работать как задумано. Поднимутся остальные интерфейсы - пойдёт и через них трафик. В общем, средний сервак поднимется при любом порядке запуска демонов и поднятия железок.

Фактически единственное что имеет смысл сделать в первую очередь - смонтировать /proc и /sys и поднять lo. Это, в общем-то единственная реально существующая зависимость в линуксе, существование которой совершенно не требует какой-то специальной фигни.

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

Stanson ★★★★★
()
Ответ на: комментарий от Radjah

Что за калькулятор вместо компа?

4-хксеоновые монстры с четвертью терабайта памяти, на которых крутится кластер БД. Хоть обдрочись на системде, а пока включённая нода не сольёт те гигабайты данных которые были пропущены при простое - никакой системде ничем не поможет вообще.

Так что есть системде, нет системде - никакой разницы вообще на самом деле нету. Скорость загрузки системы до состояния up and running настолько мало зависит от системы инициализации, что этим мизерным различием можно запросто пренебречь.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Эти говноциферки вообще ни о чём не говорят

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

с таким же успехом можно тупо запустить всё скопом, с & из единственного скрипта

Ты действительно такой, или прикидываешься? systemd строит дерево зависимостей. OpenRC в этом плане немного халатен, но всё же вполне справляется со своей задачей.

Это та же херня что и с виндой - раз-два и уже десктоп. А работать один хер невозможно ещё пару минут..

С предложенным тобой способом — да.

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

Как раз говорят, и достаточно точно.

Ну и где там тайминг запуска хотя бы MariaDB c базёнкой хотя бы в десяток гигов, например?

Вообще, на сервере эти циферки довольно важны, так как даунтайм должен быть минимален

Ну так продемонстрируй, насколько твой системде ускорит запуск вышеупомянутой MariaDB. Пока оно не поднялось - сервер в дауне. Хоть там 100500 системде установлено.

Ты действительно такой, или прикидываешься? systemd строит дерево зависимостей.

Расскажи мне на конкретных примерах с распространёнными демонами от апача до какого-нибудь ntpd нахера там вообще эти зависимости нужны. А то что-то зависимостей хотят почему-то только всякие идиотские поделки десктопные.

С предложенным тобой способом — да.

Оно ничем не отличается от того, что пытается делаеть системде. Форкнуть в бэкграунд тормозные процессы - много ума не надо. Зависимости - тупая отмазка, большинство нормального серверного софта их не требует.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Расскажи мне на конкретных примерах с распространёнными демонами от апача до какого-нибудь ntpd нахера там вообще эти зависимости нужны.

Нафига тебе ntpd без сети? Вначале нужно поднять сеть. Как поднять сеть, если ФС с конфигами ещё не примонтирована? Примонтировать сеть. И так далее. Тебе не нужно беспокоиться обо всех этих деталях, ты включаешь ntpd в автозапуск, остальное за тебя делает софтина. Проще, чем вендовое Далее → Далее → Далее → Готово.

Оно ничем не отличается от того, что пытается делаеть системде.

И всё же я начинаю подозревать, что тебя часто били по голове. Помимо зависимостей оно ещё и ждать готовности умеет, а не тупо запускалка софта. А твои скрипты запустят всё скопом, половина отвалится из-за неготовности второй половины, а потом сиди в ssh (если сеть поднимется вообще), и разруливай.

r3lgar ★★★★★
()
Ответ на: комментарий от r3lgar

Нафига тебе ntpd без сети?

А ntpd насрать, есть ли сеть при запуске или нет. Появится сеть - он достучится до серверов, нет сети - будет ждать.

Кроме того, ntpd, если ты не в курсе, прекрасно может использовать в качестве источника точного времени локальный GPS, радио или там локальные атомные часы. man ntp.conf и всё такоэ.

Вначале нужно поднять сеть. Как поднять сеть, если ФС с конфигами ещё не примонтирована? Примонтировать сеть.

А чтобы примонтировать сеть надо поднять сеть :) И как раз вот тут системде начинает вытворять такоэ! :) Не, лучше бы Поттеринг не рождался вовсе. :)

И так далее. Тебе не нужно беспокоиться обо всех этих деталях, ты включаешь ntpd в автозапуск, остальное за тебя делает софтина.

Ага. И при отмирании одного интерфейса системде берёт и прибивает ntpd. Зависимости такие зависимости.

Stanson ★★★★★
()
Ответ на: комментарий от r3lgar

А твои скрипты запустят всё скопом, половина отвалится из-за неготовности второй половины

Пример в студию. Только не высосанный из пальца, а реальный.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Пример в студию. Только не высосанный из пальца, а реальный.

dhcpd. Реальный пример? Или будешь утверждать, что сфероконина?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.