Comments 437

А почему bash-completion так лагает при выводе подсказок по systemd? Это и на нескольких последних версиях Убунты, и на других дистрибутивах, судя по аналогичным вопросам на stackoverflow. Лечения так и не нашел.

Ну, надо идти и смотреть, что там в completion навернуто. Не говоря о том, что это могут проблемы попросту конкретного дистрибутива.

По правда говоря, это пост не о войнах systemd. Если хотите почитать ещё, но лень копаться в списках рассылки, то держите чей-то материал, который отчасти вдохновил меня на этот пост

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

Честно скажу: я не дочитал до конца. Вообще, я боялся, что статья получится чересчур большой, и на этот блог наткнулся где-то позавчера, ближе к концу написания материала, в общем, не осмелился приводить его полностью.
Я думал, тут будет перевод именно этой, самой важной части статьи.

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

Представьте, что вам нужен понятный и легко читаемый rc-script который:


  • запускает некий процесс, при этом:
    — гарантирует наличие сети к моменту его запуска
    — гарантирует наличие определенных mount-points к моменту запуска
  • перезапускает его если он вылетает при определенных кодах возврата
  • не даёт запустить больше чем один процесс (при повторных вызовах)
  • адекватно завершает процесс при shutdown но до того как отключатся сеть и некоторые другие процессы
  • всё вышеперечисленное должно работать одинаково (и надёжно) в debian/arch/centos

Сколько строчек получилось? И насколько понятно-читаемых?

Давайте я парирую вас по пунктам.
запускает некий процесс, при этом:
— гарантирует наличие сети к моменту его запуска
— гарантирует наличие определенных mount-points к моменту запуска

Такого не должно быть в правильном софте. Софт должен самостоятельно проверять необходимые ему зависимости, а не полагаться на третьи в общем виде недоваренные сервисы.

перезапускает его если он вылетает при определенных кодах возврата

Такие вещи нельзя отдавать на сторонний софт. А что будет, если успешное условие запуска так и не произойдёт? Вы получите постоянно перезапускающийся сервис.
не даёт запустить больше чем один процесс (при повторных вызовах)

Десятки лет это решалось наличием файлика daemon.pid в run директории.
адекватно завершает процесс при shutdown но до того как отключатся сеть и некоторые другие процессы

Опять же это должен делать сам софт, а не внешняя система запуска.
всё вышеперечисленное должно работать одинаково (и надёжно) в debian/arch/centos

Как раз с этим проблем не было.
Такого не должно быть в правильном софте.

Вместо того чтобы сделать инструмент который удовлетворяет большому количеству сценариев, говорить что ваши сценарии неправильные — это путь в никуда.

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

По такой логике правильного софта не существует.


Вы получите постоянно перезапускающийся сервис.

Поэтому systemd позволяет ограничить частоту и количество перезапусков.


Десятки лет это решалось наличием файлика daemon.pid в run директории.

Который можно случайно (не) удалить или случайно не создать. Или вообще устроить race condition. Это очень ненадёжно.


Опять же это должен делать сам софт, а не внешняя система запуска.

Зачем переусложнять софт тоннами проверок, если всё это может делать система инициализации? В чём смысл?

Софт должен самостоятельно проверять необходимые ему зависимости, а не полагаться на третьи в общем виде недоваренные сервисы.

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


Такие вещи нельзя отдавать на сторонний софт. А что будет, если успешное условие запуска так и не произойдёт? Вы получите постоянно перезапускающийся сервис.

Постоянно перезапускающийся сервис вы получите если будете делать защиту от падений "на коленке". А systemd умеет останавливаться при повторяющейся ошибке.


Десятки лет это решалось наличием файлика daemon.pid в run директории.

Ага, и с гонками вокруг того файла.

Софт должен самостоятельно проверять необходимые ему зависимости, а не полагаться на третьи в общем виде недоваренные сервисы.

То есть каждый софт который работает с сетью должен сам эту самую сеть настроить и запустить? А если ему нужен доступ к какому-то NFS то ещё и его подмонтировать?


Вы фактически предлагаете любое приложение превращать в отдельную OS.


А что будет, если успешное условие запуска так и не произойдёт? Вы получите постоянно перезапускающийся сервис.

Если условия для запуска не наступают — то логично что сервис не запустится вообще и "запускатель" будет ждать (с минимальным оверхедом) наступления условий (что делает systemd — и отлично делает). В случае с rc-script всё зависит от кривизны рук его писателя (обычно они кривые).


Вообще отслеживание зависимостей запуска должно быть сделано вне самого приложения — потому что приложение (сервис) может банально не иметь прав/знаний чтобы эти самые зависимости запустить/реализовать, всё что оно должно "мочь" — это сказать что ему нужно, а не как и где.


Десятки лет это решалось наличием файлика daemon.pid в run директории.

Угу… как уже упомянули выше — с этим связаны массы race conditions, не говоря уже о том что pid-file — это только поллинг, со всеми вытекающими.


Опять же это должен делать сам софт, а не внешняя система запуска.

Да без проблем — сервису для работы с (допустим) почтой доверим shutdown системы и корректное завершение работы БД, чтобы он успел всё что нужно сделать. Примерно так?

Десятки лет это решалось наличием файлика daemon.pid в run директории.

лол, как будто не может быть гоночек в системе и этот pid будет кому-то другому назначен (я такое хватал). Проверка по pid — это, к сожалению, не самое надежное, что есть в этом мире.

init.d скрипты понятные? Один и тот же скрипт делающий одно и то же будет раз в 5 длинней, чем в systemd
Представьте, что вам нужен понятный и легко читаемый rc-script который:.....

Захожу по SSH в FreeBSD и вижу там скрипты которые делают все это и многое другое.
Причем написать свой не представляется большой трудностью даже без частых подглядываний в интернет только на основе того, что уже есть в базовой системе.
Как говорил Жванецкий: «Может нужно что-то в консерватории подправить?»

Могу только съязвить, что линуксы между собой могут отличаться больше, чем Линукс (произвольный) отличается от бсд.
Ну, и, конечно, брать бсд как пример. Такое себе. Система хорошая, но больно узкоспециализированная по нынешним временам

Захожу по SSH в FreeBSD и вижу там скрипты которые делают все это и многое другое.
А статью не напишите? Про то, как всё устроено. И как система поднимается, ждёт получения имени по DHCP, после чего решает откуда понтировать (через NFS) Web-сайтик и только после этого запустить Web-сервер. А FTP-сервер (монтирующийся с другого NFS-сервера) дожен, разумеется, работать даже если Web-сервер не поднялся.

Банальная такая задачка — будет интересно посмотреть как именно FreeBSD это всё разрулила. Кроме шуток.

Как говорил Жванецкий: «Может нужно что-то в консерватории подправить?»
Может быть. Статью реально жду. Потому что количество костылей, которые требовалось забить, чтобы что-то подобное сделать на бездисковых станциях под Linux у нас в школе… вызывало некоторую оторопь.

Бездисковые станции ушли в прошлое, но теперь те же самые задачи возникают на серверах. Если FreeBSD это успешно и надёжно решает скриптами — то будет интересно на это посмотреть.
DHCP, NFS, вебсайтик через nfs и только потом запуск вебсервера — странно читать это все через запятую, особенно первые два пункта. А в этом точно есть необходимость (особенно на продакшене)? Больше похоже на сферического коня в вакууме.
Больше похоже на сферического коня в вакууме.

больше похоже на машинку разработчика, который не осилил в докер или кубер :-D
/шутка, в которой доля шутки/

А статью не напишите? Про то, как всё устроено. И как система поднимается...

На хабре много блогов, где коммерсы выкупили посты, а несчастные сотрудники потом занимаются переводом англоязычных статей и документации. Для них как раз идея подойдет. Остальным я бы посоветовал просто читать документацию, а не мои опусы.
по DHCP, после чего решает откуда понтировать (через NFS) Web-сайтик и только после этого запустить Web-сервер. А FTP-сервер (монтирующийся с другого NFS-сервера) дожен, разумеется, работать даже если Web-сервер не поднялся.

Здесь все просто:
image
Я думаю, все от того, что на той же самой машине не пытаются одновременно запустить Tensorflow, PyTorch, майнер и еще IP-телефония для жилого квартала куда-то пропала.
Ну да, всё понял: вы его неправильно держите.

Спасибо за рекламу systemd.
Представьте, что вам нужен понятный и легко читаемый rc-script который:

Давайте лучше не rc, с ними всё понятно, а лучше рассмотрим run-скрипт для Runit.


• запускает некий процесс, при этом:
— гарантирует наличие сети к моменту его запуска
— гарантирует наличие определенных mount-points к моменту запуска

Сеть и монтирования в Runit выполняются на 1-м (синхронном) этапе загрузки, до начала запуска (асинхронного) всех сервисов. Выглядит это примерно так:


mount -at noproc,nofuse
swapon -a

ip link set lo up
iptables-restore </etc/iptables

ip link set eno1 up
ip addr add 1.2.3.4/24 dev eno1
ip route add default via 4.3.2.1 dev eno1

• перезапускает его если он вылетает при определенных кодах возврата

Runit это супервизор, который контролирует сервисы по SIGCHLD — иными словами сервис не должен демонизироваться, но зато нет никаких pid-файлов и race, сервис будет гарантированно автоматически перезапущен (1 раз в секунду если он непрерывно падает).
Можно добавить (однострочный) finish-скрипт, который выключит сервис если он завершился с определённым кодом возврата (чтобы он перестал перезапускаться).


• не даёт запустить больше чем один процесс (при повторных вызовах)

Не даёт, разумеется. Попытка запустить уже запущенный сервис успешно завершается ничего не сделав.


• адекватно завершает процесс при shutdown но до того как отключатся сеть и некоторые другие процессы

Отключение сети и маунтов выполняется на третьем (тоже синхронном) этапе, после того как был инициирован shutdown/reboot и второй этап (запустивший все сервисы) был завершён (сервисы были остановлены).


• всё вышеперечисленное должно работать одинаково (и надёжно) в debian/arch/centos

Так и работает, достаточно поставить и запустить runit.


Сколько строчек получилось? И насколько понятно-читаемых?

Ну, как сказать. Приведу несколько примеров. Начнём с простого: sshd.


$ cat /etc/sv/ssh/run
#!/bin/sh
exec &>/var/log/all/.log
exec /usr/sbin/sshd -D

Но это скучно. Давайте что-то по-сложнее, dbus:


$ cat /etc/sv/dbus/run
#!/bin/sh
exec 2>&1
mkdir -p /var/run/dbus
rm /var/run/dbus.pid
dbus-uuidgen --ensure=/etc/machine-id
exec dbus-daemon --nofork --system

Ну или давайте что-то с зависимостями от других сервисов, напр. postfix:


$ cat /etc/sv/postfix/run
#!/bin/bash
exec 2>&1
sv start /etc/service/postsrs &>/dev/null || exit
sv start /etc/service/postgrey &>/dev/null || exit
sv start /etc/service/opendkim &>/dev/null || exit
sv start /etc/service/opendmarc &>/dev/null || exit
exec postfix start-fg

Ну и на закуску X-ы:


$ cat /etc/sv/x/run
#!/bin/bash
exec &>/var/log/all/.log
sv start /etc/service/*tty* &>/dev/null || exit
sv start /etc/service/dbus &>/dev/null || exit
sv start /etc/service/elogin &>/dev/null || exit
. /etc/profile
exec slim -nodaemon

Как Вам количество строчек и их читаемость?


P.S. Забавный факт: официально в runit вообще нет поддержки зависимостей между сервисами, считается, что если сервис при запуске не нашёл чего-то необходимого, то он просто упадёт и будет перезапущен 1-2 раза (а в тому моменту сервисы, от которых зависит этот уже будут готовы к работе). Так что вышеупомянутая "реализация" зависимостей между сервисами — это по большей части моё баловство, не всегда обязательное. Полноценная поддержка зависимостей есть в S6, так что кому не хватает функционала Runit просто берёт S6, там намного больше фич.

Выглядит круто, но есть куча вопросов


  1. что с параллельностью запусков сервисов? То что здесь я вижу — скорее последовательный запуск. То что я увидел у Вас — это не зависимости, а чертизнаетчто.
  2. в systemd основная фишечка — это расширяемость и переопределение. Вот, скажем, постфикс — он притаскивает свой системный юнит. Меня он не устраивает. Что я делаю? Я закидываю переписанный юнит на /etc/systemd/system или дроп-ины туда и я уверен, что при обновлении пакета постфикса мои изменения не будут перезаписаны. Это на самом деле очень важно.
  3. Что делать если нужны дополнительные возможности — вроде засовывания целых поддеревьев процессов в це-группы, лимитирование по памяти, процессору и прочие продвинутые штуки?

И многое другое. Я так понимаю, что в рамках примера "runit — простой до безобразия" Вам это не удалось сделать. В ключе же, что "соберу свой дистрибутив с нуля" — да, это возможно альтернативный, возможный подход. Но точно не в production, чтобы все было унифицированно, понятно, исправляемо любым квалифицированным инженером (=поддерживаемо) и относительно дешево.

Сервисы запускаются параллельно всегда. Где Вы там увидели последовательный запуск — я без понятия. Ещё раз, у runit 3 стадии работы:


  1. На первой выполняется один скрипт, который инициализирует систему синхронно (mount, udev, fsck, sysctl, net — вот это вот всё). Тут нет особо долгих или блокирующих операций, поэтому выполняется он за 3-5 секунд, что не имеет никакого значения, учитывая как часто перегружаются машины.
  2. На второй одновременно запускаются все сервисы, без учёта каких-либо зависимостей. Если каким-то сервисам чего-то нехватило — они падают и автоматически перезапускаются через 1 секунду.
  3. Третья запускается в момент shutdown/reboot, это тоже один синхронный скрипт как на 1-й стадии, он сначала останавливает все сервисы, а потом выполняет необходимые операции перед отключением (hwclock, alsactl, random, net, umount). Он так же отрабатывает за пару секунд.

В целом, такое разделение операций на синхронные (1,3) и асинхронные (2) позволило сильно упростить всё — и реализацию самого runit, и понимание мной как админом что и как происходит при загрузке и отключении системы.


Вот, скажем, постфикс — он притаскивает свой системный юнит. Меня он не устраивает.

Ну, в Runit с этим всё хорошо. В смысле, postfix ничего про runit не знает, и своих юнитов не притаскивает. Вышеупомянутый мной run-файл пишется ручками, под нужды текущей системы. Напр. у моего папы на компе postfix нужен чисто для отправки почты (можно было какой-нить ssmtp поставить, наверное), поэтому у него run-файл postfix выглядит вот так:


#!/bin/sh
exec postfix start-fg 2>&1

И да, представляете, написать такое руками займёт примерно столько же времени, сколько установить этот файл каким-нибудь apt install postfix-runit.


По сути, я именно это и пытаюсь Вам всё это время объяснить: загрузка системы и запуск сервисов может (и должен) быть намного-намного проще, чем это сделано в sysvinit и systemd.


засовывания целых поддеревьев процессов в це-группы, лимитирование по памяти, процессору и прочие продвинутые штуки?

Ну, тут такое дело. Если Вам реально необходимы все те продвинутые фишки systemd — значит надо использовать systemd и платить запрошенную им цену (сложность), потому что в этой ситуации данная цена является приемлемой.


Но лично из моего опыта — в этих фичах просто нет необходимости… для типовых системных сервисов. Они слишком давно существуют, написаны и отлажены достаточно хорошо, и не замечены в безудержном пожирании системных ресурсов. Иными словами, изолированы они по cgroups или нет — на работе системы это никак не сказывается. А сервисы не системные, наши собственные, реализующие работу нашего проекта, под который этот сервер, собственно, и был запущен — это совсем другое дело, и для них ограничивать ресурсы действительно необходимо… только вот это уже отлично делает докер/куб. (Иными словами, systemd в этом месте опять успешно решил не существующую на практике проблему.)


P.S. Впрочем, если речь не о cgroups, а о более традиционных ограничениях (chroot, uid/gid, env, ulimit, …) то для этого существует куча мелких утилит (идущих в комплекте и с daemontools, и с runit, и с s6 — напр. вот chpst из runit), которые обычно вызываются из run-файла цепочкой. Например, запуск внутри chroot под юзером nobody (плюс обновление бинарников и so-библиотек внутри chroot-каталога):


$ cat /etc/sv/3proxy/run
#!/bin/sh
exec 2>&1

# update binaries and libraries
for f in $(find root/ -type f -perm /001 | sed s,^root,,); do
    cp "$f" "root$f"
done

exec chpst -/ root/ -u nobody /usr/bin/3proxy /etc/3proxy.cfg
выполняется он за 3-5 секунд

У меня через 5 секунд уже графическая форма логина отображается, при том что ещё даже не все USB-устройства проинициализированы на тот момент.


они падают и автоматически перезапускаются через 1 секунду.

Бессмысленное засирание логов тоннами ошибок, systemd в этом плане явно лучше.

Ну, насколько я понимаю, львиную часть этих 3-5 секунд съедает как раз блокирующая инициализация udev (т.е. по сути код Вашего любимчика Поттеринга). Впрочем, это не важно. Если кому-то экономия 2-3 секунд на перезагрузке компа компенсирует сложность systemd — значит он понимает, зачем ему нужен systemd и всё в порядке. Я лично комп перегружаю примерно раз в месяц для обновления ядра, и мне эта экономия сложность systemd точно не компенсирует. (Кстати, на соседнем компе Debian 10 с systemd, и я что-то не замечал, чтобы он грузился быстрее моего, а точнее он грузится заметно медленнее, хотя в автозапуске у него меньше всего и нет браузера, в отличие от моего компа.)


Бессмысленное засирание логов тоннами ошибок

Ну вот откуда вы все это берёте… Между сервисами не так много зависимостей (особенно если не считать "сервисами" вещи вроде fsck/mount/net — которые в Runit делаются до запуска всех сервисов), они не так часто умудряются запуститься настолько неудачно, чтобы это сломало зависимости и кто-то из них упал, плюс вышеупомянутый мной пример проверки зависимостей прямо в run-файле позволяет просто не запускать сервис (и не писать ничего в лог) пока зависимости не готовы. В результате в логах если и бывают ошибки на эту тему, то буквально одна на все сервисы, и то не при каждом перезапуске. (Иными словами systemd опять решил несуществующую проблему.)

Ну вот откуда вы все это берёте…

Из практики. Какой-нибудь danted зависит от сетевых интерфейсов, какой-нибудь Django-сайт зависит от запущенного MySQL и насыпет ошибок в лог при его отсутствии, и так далее


вышеупомянутый мной пример проверки зависимостей прямо в run-файле

И это всё вместо того, чтобы написать одну строчку?


After=opendkim.service opendmarc.service mysqld.service


Ваш пример является отличной антирекламой runit. Я предпочту написать одну строчку декларативного конфига, чем десяток строчек мутных скриптов с кучей ручных проверок.

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

Ну, как сказать "забить". Если юзеры честно получали эти 500-е — я бы хотел видеть их в логах, это поможет саппорту разбирать жалобы юзеров.


Но в общем случае всё, что я тут пишу про runit — это про системные сервисы. Я не принимаю во внимание запуск самописных и прочих "enterprise" сервисов на java и нужных им БД, потому что всё это обычно запускается в докере/кубе, и проблемы эти разруливаются (или нет) средствами докера/куба. Нет, серьёзно, когда-то действительно выкатывать их ансиблом в systemd было разумным, но в 2020-то зачем так делать?

в 2020-то зачем так делать?

Затем, что почему бы и нет? Выкатываю ансиблом в systemd все свои серверы и радуюсь жизни. Зачем тратить драгоценные ресурсы вдсок на жирнющий докер и возиться с его настройкой и написанием обмазанных костылями докерфайлов — не знаю. (У ансибла, впрочем, есть свои недостатки, но systemd тут уже ни при чём)

Вопрос "зачем нужен докер для собственных сервисов" несколько выходит за рамки обсуждения systemd. Но в ответе на него обычно звучат слова "тесты/CI, контроль внешнего окружения, простота запуска проекта на машине разработчиков, лёгкая переносимость между серверами, …".


Насчёт жирнющий и настроек — первый раз слышу такие претензии в отношении докера, особенно в контексте enterprise-java-сервисов, на фоне которых демон докера теряется по определению. А настройка обычно сводится к перенаправлению логов в более подходящее место и запуску docker swarm init|join.

особенно в контексте enterprise-java-сервисов

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


А слова "тесты/CI, контроль внешнего окружения, простота запуска проекта на машине разработчиков, лёгкая переносимость между серверами, …" легко реализуются и без докера, если руки из правильного места растут.


лёгкая переносимость между серверами

да-да-да, это пока не выясняется одно из нескольких:


  1. версия докера не та (были проблемы, если образы собранные последним докером запускать на более старом)
  2. нужны какие-то специфичные sysctl (напр., для запуска эластика)
  3. пока архитектура процессора та же — если скомпилировали код с оптимизациями под xeon, то он запросто может не запуститься на amd — тупо illegal instruction и все. Это как бы не собственно проблема докера, а ложь об обещаниях переносимости (она сама внезапно не появляется, но современному поколению это неизвестно)
  4. пока не нужно засунуть systemd внутрь докера — там целая эпопея с приключениями
  5. пока не нужен специфичный драйвер оборудования
  6. пока не нужен privileged режим

    где-то тут еще могут стрельнуть особенности работы сети с докером (привет, телефония и прочие штуки) или особенности работы с диском

и масса другого. Т.е. отрицать то, что докер отрыл новую страницу в истории и популяризировал контейнеризацию нельзя. Но натянуть на него все возможные юзкейсы… попросту нормально не получается. Да и не нужно.


docker swarm init|join.

swarm мертв, закопайте его труп и забудьте его уже.

напр., для запуска эластика

Это какие? Разве что число дескрипторов, но такие вещи делаются на самом хосте.
Разве что число дескрипторов, но такие вещи делаются на самом хосте.

так об этом и речь! Переносимости нет (контейнер стартанет и упадет) — пока не настроишь хост. В общем-то возможно пример не особо честный, но просто надо иметь в виду, что абстракции текут. И это надо уметь учитывать.

managed сервер или кластер. Нам только докер/кубер ендпоинты открыты.

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

Дефолтный образ эластика в докере на дефолтных настройках убунты вроде тупо не поднимается.

Ну не знаю. У меня эластик docker.elastic.co/elasticsearch/elasticsearch:7.6.1 на обычной убунте. Индекс на 100гб, 5 шардов, все норм.

У нас шестой используется. Он прямо в логе при первом старте писал, что увеличьте пару значений и падал. Ещё вообще без наших данных.

swarm мертв, закопайте его труп и забудьте его уже.

Standalone swarm — да. Встроенный в докер — живее всех живых, и отлично заменяет намного более сложный куб в большинстве мелких/средних проектов.

жирнющий докер

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

все так, но иногда оверхед от докера вылезает :-/

100-150МБ оперативы на демон докера — раз.


Гигабайт-другой на скачивание образов ubuntu/debian/alpine, причём в разных контейнерах разные их версии — два.


Оверхед на сеть, на что жалуются примерно все пользователи докера — три.


И всё это пихать на вдску с 1ГБ оперативы и 10ГБ HDD? Спасибо, не надо.


Плюс полно других рантаймов, которые легче

В любом случае мне и без докера хорошо.

Гигабайт-другой на скачивание образов ubuntu/debian/alpine, причём в разных контейнерах разные их версии — два.

Алпайн весит 3МБ, убунта 30МБ. О чем вы?

Оверхед на сеть, на что жалуются примерно все пользователи докера — три.

На подобной вдске? Смешно. А что до жалоб — я не встречал подобных жалоб за года работы с докером (что скорее означает, что проблемы либо нет, либо она вызвана не докером, либо встречается в очень специфичных кейсах), а исследование IBM показывает ничтожную разницу, которую чтобы разглядеть в продакшене я не знаю что надо делать. А уж когда работаешь на таком уровне, то как правило есть железо, чтобы было пофиг на этот оверхед.

Что до оперативки, если 100мб это настолько дорого, то это уж совсем какой-то странный кейс. Но ладно, кому-то может надо экономить даже настолько.
Алпайн весит 3МБ, убунта 30МБ.

В реальном использовании на многочисленных разных образах набегает несколько гигабайт.


это уж совсем какой-то странный кейс.

Рад за вас, если у вас завались денег и вы можете скупать дедики целыми стойками, не задумываясь об оперативке. К сожалению, я не из таких. Запустится с десяток служб по 100МБ — и всё, оперативка кончилась, привет swap и OOM Killer.

В реальном использовании на многочисленных разных образах набегает несколько гигабайт.

Это уже проблема конкретных приложений, которые поверх образа убунты накатывают хренову тучу юзерспейс фигни. Сами базовые образы весят ничтожно мало.

Запустится с десяток служб по 100МБ

Откуда десяток уже взялся, когда докер один?
Откуда десяток уже взялся, когда докер один?

для меня до сих открытый вопрос — насколько хорошо докер шарит страницы памяти между одинаковыми инстансами одного приложения в нескольких репликах ( суть — в разных контейнерах, можно даже из разных, но бинарно идентичных образов).

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

Вы же понимаете, что на сервере докер будет далеко не единственным процессом?

Вы просто странно перешли с докера на 100мб до десятка сервисов по 100мб, будто тут докер виноват в этих сервисах. А так, ну да, вместо десяти сервисов запустить получится 9. У меня правда подозрение, что в настолько ограниченной среде, OOMKiller придет запросто и без всяких докеров. Как у вас там вообще все работает? Своп есть хотя бы? Но так да, если счет на мегабайты, докер тут лишнее звено. Я действительно привык работать с серверами, где контейнеров сотни крутится, поэтому один докер демон там это капля в море.
будто тут докер виноват в этих сервисах

Ну так докер один из сервисов. Если у меня есть возможность не занимать лишние 100МБ — зачем мне их занимать? Я их лучше мускулю выдам, чтобы он чуточку быстрее запросы выполнял.


А ситуации, когда я буду готов пожертвовать 100МБ памяти, гигабайты образов и денежку на более мощный сервер ради какого-нибудь фатального преимущества докера, у меня пока не возникало.

Вот как раз у докера таких средств нет, у докер-композ почти нет, а у кубера опять нет.

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

Да! :) Но делать-то нечего, запускается всё это всё-равно в докере… так что наличие этих средств у systemd ничем не поможет.


На самом деле не знаю, как насчёт вырожденного кейса с подключением единственного сервиса-вебсайта к БД, может в этом случае разработчики ленятся нормально написать код (пере)подключения. Но обычно в мире микросервисов ситуация, когда внезапно отвалился какой-то сервис из тех, от которых зависит текущий сервис — штатная. Поэтому код всегда пишется так, чтобы это не создавало проблем, и (пере)подключение происходит в фоне, как на старте сервиса так и в процессе его работы. И в этом случае нет никакой необходимости отслеживать зависимости между сервисами на уровне их супервизора.

Падение базы это вообще не штатная ситуация. Это катастрофа, поэтому 500 ошибки это нормально. 500 ошибки на старте сервиса, потому что он стартанул раньше базы, это не нормально. И решать это можно двумя способами — указать зависимости через init систему или делать это в коде. Тут дело вкуса.

База, обычно, часть сервиса. И вот тут какой-нибудь сервис дискавери видит, что сервис есть, 80-й порт слушает, а по факту у него один ответ — 500 с каким-нибудь mysql has gone

«Так делать не надо» это не аргумент. Люди делают так и для этого полно причин, иногда чисто технических, когда вне докера работает лучше и быстрее. У вас за скромные несколько постов здесь уже набралась пачка «зачем так делать». Все это лишь показывает, что ваш runit не решает реальные задачи или требует для этого помойку из скриптов, от которой все как раз и хотели уйти.
У вас за скромные несколько постов здесь уже набралась пачка «зачем так делать».
Угу. И при этом ещё усиленное педалирование количества Issues.

Конечно если все баги закрывать с WONTFIX или NOTERROR — то ни одного бага в таком софте не будет.

Но захотите ли вы им пользоваться?

Антиреклама Runit получилась знатная, надо сказать…
Конечно если все баги закрывать с WONTFIX или NOTERROR — то ни одного бага в таком софте не будет.

либо, как сделала одна компания с китом на лого продукта, тупо мигрировать в новый репо — и все старые ишью закрыть. Нет репо — нет ишью — нет проблем /шутка, в которой доля шутки/

Если каким-то сервисам чего-то нехватило — они падают и автоматически перезапускаются через 1 секунду

Потрясающий ход, конечно.

Таки да! Простой, очевидный, и надёжный. Из потенциальных недостатков разве что "засирание логов", но я про это ответил выше — на практике этой проблемы нет.

Да, трата. Но во-первых это количество ресурсов пренебрежимо мало, и во-вторых вовсе не бесполезная: её польза в возможности использовать значительно более простой и надёжный инструмент — runit.

Это ваше мнение, что они пренебрежимо малы? А если сервис тяжелый и требует много ресурсов на запуск только для того, чтобы упасть, потому что сеть видите ли не поднялась еще? Односекундная задержка это типичное решение скрипткидди, которые не умеют в координацию процессов. Если сервисов несколько, то рано или поздно будет ситуация, когда все сервисы одновременно падают и перезапускаются, тратят кучу ресурсов на это. Мое мнение, подобных подходам нет места в современных ОС. В embedded и прочих мелких устройствах — может быть. Там фиксированная конфигурация, нет смысла городить огород. Там и обычные rc скрипты устраивают.

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

Если каким-то сервисам чего-то нехватило — они падают и автоматически перезапускаются через 1 секунду.

Фактически, это busy wait. Ничего хорошего в нём не вижу.
И не факт, что они потом перезапустятся.


Вот ситуация в моём случае: имеется сервер OpenVPN, серверу требуется сетевой мост. Так вот иногда случается, что при старте системе он запускается слишком быстро — раньше, чем поднимется мост, из-за чего сервис не упадёт, а будет просто работать некорректно. То есть придётся сначала зайти по ssh и перезапустить сервис.

В runit сеть настраивается до запуска всех сервисов.


Иными словами, описанная Вами проблема сначала была искусственно создана (кто-то решил, что абсолютно всё-всё надо сделать "сервисами" и запускать асинхронно), а потом потребовалось героически и с кучей лишних сложностей её решать.

У вас очень opinionated view. Сеть и ее настройки — это не монолит. Как пример, ВПН запускается только тогда, когда есть активный интерфейс. Или на фрилансим регулярно вижу — напишите скрипт, который ВПН внутри впна, который внутри третьего впна. На системди не без боли, но сделаешь. На runit?

Честно говоря, мне такое делать пока не приходилось. Насколько я понимаю, при использовании wireguard это всё заработает автоматически, достаточно просто запустить все три. При использовании OpenVPN, вероятно, придётся добавить в run-файл VPN2 зависимость от наличия нужного интерфейса VPN1 (предположим, VPN1 поднимает tun1, VPN2 поднимает tun2, …):


### в начале /etc/sv/openvpn2/run:
ip link show tun1 &>/dev/null || exit

но вот что случится если/когда этот интерфейс временно отвалится — вопрос любопытный. Если само не заработает, то придётся в finish-скрипт первого openvpn добавить перезапуск зависящего от него второго:


### в /etc/sv/openvpn1/finish:
sv t openvpn2
в начале /etc/sv/openvpn2/run:

ip link show tun1 &>/dev/null || exit

Разрешите потроллить? А чего iproutes, а не старый добрый ifconfig? Или все-таки достижения последних лет не так плохи (включая сустемди)?

Достижения последних лет бывают полезные и не очень. К счастью, iproute2 можно взять не беря "в нагрузку" systemd.

Ага, а теперь добавлю пикантную подробность: изначально всё настраивалось в Ubuntu 14 (без systemd).

В runit сеть настраивается до запуска всех сервисов.
Гениальность просто зашкаливает. Напоминает историю с мой прошлой работе, когда экскаватор перерубил оптику и ни один комп нельзя было перезагрузить пока сеть не восстановится, так как они все банально висли на этапе «достучаться к NFS-серверу из соседнего офиса».

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

Иными словами, описанная Вами проблема сначала была искусственно создана (кто-то решил, что абсолютно всё-всё надо сделать «сервисами» и запускать асинхронно), а потом потребовалось героически и с кучей лишних сложностей её решать.
Отчасти согласен. С тем только лишь замечанием, что вот как раз «поднятие сети» и «монтирование файловых систем» — точно нужно делать асинхронно.

Да, в некоторых ситуациях поднятие некоторых сетевых интерфейсов (OpenVPN, например) и монтирование некоторых сетевых файловых систем (не критичных для основного функционала сервера) действительно надо делать асинхронно (и это без проблем делается в runit).


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

Сеть и монтирования в Runit выполняются на 1-м (синхронном) этапе загрузки
Отлично. У нас упал NFS-сервер отвечающий за /home/build (без него система вполне работоспособна, только не работает распределённая сборка… она не всем и не всегда нужна).

Как Runit разрулит эту проблему, когда я смогу войти в свою любимый GNOME (KDE, XFCE, нужное подчеркнуть) и, главное, что будет с теми сервисами, которым нужен-таки /home/build?

Полноценная поддержка зависимостей есть в S6, так что кому не хватает функционала Runit просто берёт S6, там намного больше фич.
Как именно происходит переход?

Потому что главная претензия к systemd — это то, что «если мне это всё нинужна, то я не хочу всё это изучать». Два системы, от одной из которых можно плавно и безболезненно перейти к другой и обратно — это решение… но вот насколько прост как раз этот переход?

Не знаю, мне пока хватало возможностей runit. Но если/когда понадобится что-то, чего runit не умеет — буду переходить на s6.


Немного напрягает то, что runit вообще не развивается много лет — автор считает его "законченным". В каком-то смысле так и есть, он делает всё необходимое (из поставленных перед ним изначально задач) и делает это хорошо — багов нет, всё работает. Но опыт показывает, что в long term эта стратегия с софтом, к сожалению, не работает — окружающий мир меняется, и достаточно сильно, поэтому софт, который этот факт игнорирует и не развивается вместе с миром — умирает. Пока что изменения мира никаких проблем с runit не создали, но первый "звоночек" уже прозвучал — поддержка cgroups выглядит интересной, хоть и не особо нужной (для системных сервисов) фичей… только вот уже появился сервис elogind (вытащенный logind из systemd) которому для работы нужны предоставленные менеджером сервисов cgroups (к счастью, в нём есть возможность реализовать этот функционал в нём самом, а не ждать его от менеджера сервисов, так что пока обошлось). А вот S6 активно развивается, так что "путь отхода" с runit доступен, если он вообще понадобится, конечно.

поддержка cgroups выглядит интересной, хоть и не особо нужной (для системных сервисов) фичей…

Вы думаете, что ненужной, а вот когда у нас на корп сервер, где пасется 100+ не могли войти, из-за того, что пользовательские сессии были кривые… Ну, Вы поняли ) Там бы цегруппы пригодились

А почему однотипный код в программах выносят в функции, а не дублируют его?

Понятных? Не соглашусь. Мне понадобилось написать самому первые такие скрипты незадолго до того, как в arch пришел systemd. Так что я точно могу сказать, что без опыта разобраться в systemd'шных сервисах оказалось проще и быстрее (а я смотрел, как решить мою задачу на убунте, центоси и когда я отчаялся — полез гуглить, узнал про systemd, попробовал его), и я просто поставил на тот сервер arch и решил задачу. И до сих пор рад, systemd + ansible это прям удобно.

Когда-то я пакетировал программы для нескольких дистрибутивов (и по работе, и в качестве хобби). Писать и модифицировать rc-скрипты для некоторых тяжёлых программ было очень сложно.


Слишком много времени прошло, чтобы привести конкретные примеры. Но точно помню, что проблем было очень много, особенно, с сервисами, написанными на Java.


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


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

Потому что systemd позволяет сделать запуск маленького читаемого скриптика И ЕЩЁ КУЧУ ВСЕГО, при этом оставаясь читаемым. Если кроме скриптика ничего больше не нужно, ничего не мешает сделать systemd-юнит, который будет только запускать этот скриптик и больше ничего.


Для меня знакомство с init и systemd случилось одновременно ("перепиши", говорит, "вот эти скриптики, ну ты разберёшься"), и честно скажу, systemd гораздо, гораздо понятнее и, эм, документированнее.

Не говоря о том, что уже были готовые и рабочие init'ы (runit, OpenRC, InitNG например).

Да, поддержу, что как система инициализации systemd на порядки превосходит sysvinit.
Помню, было прямо откровение, когда в первый раз здоровенная и не очень надежная баш портянка инициализации превратилась в надежный, простой и понятный systemd юнит.
А вот с journald не сложилось. Бинарный формат — печаль, т.к. не пригоден для легкого просмотра.

journald прекрасен, т.к. Вам логи глазами все равно напрямую смотреть не нужно — почти наверняка Вы логи фильтруете (стандартные текстовые) grep'ом или чем угодно, чтобы выбрать нужное. Ну, так пользуйтесь journalctl — делов-то. Это раз. Два — логи на машине это в целом ненадежная вещь — их можно сливать в некое централизованная хранилище, а там уже гуй, поиск, дашборды и все такое. Третья история, что по сути написав приложение по 12 factor app, что сейчас и не только модно, но и является необходимостью, просто пакетируете его для установки на сервер с systemd unit'ом и вуаля! Все логи собираются, красота.

По-моему journald это один из тех компонентов который тянет systemd вниз.
Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач, на самом деле нет:


time sudo journalctl -n 10 --no-pager
real    0m8,817s
user    0m0,020s
sys     0m0,059s

в то время как с того же диска и точно так же с "холодным" дисковым кэшем:


time tail -n 10 /var/log/pacman.log
real    0m0,022s
user    0m0,004s
sys     0m0,000s

Все бы ничего, но systemctl status использует journald и поэтому тоже дико тормозит: https://github.com/systemd/systemd/issues/2460


Или захочется использовать центрилизованный сбор логов и можно поиметь кучу проблем: https://habr.com/ru/company/southbridge/blog/317182/, некоторые не решаются годами: https://github.com/systemd/systemd/issues/1387

Спасибо за комментарий по существу.


https://habr.com/ru/company/southbridge/blog/317182/

Знаю такую историю. И я бы тоже не стал журналом передавать журнал на удаленную машину. У меня есть достаточные опасения (как и у Вас), что это не будет нормально работать. Но с внешним решением — будь то rsyslog или fluent-bit — все прекрасно передается по удаленному протоколу.
Еще добавлю, что была прекрасная вводная статья от Селектел по вопросу journald.

Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач, на самом деле нет:

Разрешите вопрос? А что мешает Вам в Вашей личной конфигурации подмонтировать раздел под логи с HDD-накопителя? Или вы думаете, что дефолты в конкретном дистрибутиве говно? А зачастую это так. Но тогда причем тут системди?

Например, разумно ведь в desktop системе все логи писать на HDD, а SSD использовать для более интересных задач
в 2020 году стало сложновато найти десктоп с hdd, тенденция к «hdd где-то там далеко в облаках/на серверах», а в рабочих станциях и домашних компах одни только ssd. Гибриды ssd + hdd в одной машине — издержки переходного периода, который потихоньку заканчивается.
Ну и — ничто не мешает же смонтировать hdd в /var/log.
разумно ведь в desktop системе все логи писать на HDD

У вас в 2020 году HDD на десктопе? Даже без bcache? А что-за диск, кстати, не какой-нибудь пыльный Seagate 15-летней давности или люто тормозной WD Green случайно?


но systemctl status использует journald и поэтому тоже дико тормозит

Это никому не нужно. Большинство на SSD живут. Поэтому Поттеринг разумно выжидает, пока все оставшиеся некроманты не перейдут на SSD.


Или захочется использовать центрилизованный сбор логов

Ну опять же — если очень надо, то делайте PR на гитхаб. Очевидно, что этот функционал не особо востребован, поэтому тикет висит несколько лет, а решить его некому.


Для сбора логов есть другие, более подходящие средства.

У вас в 2020 году HDD на десктопе?

Это никому не нужно. Большинство на SSD живут.
А что тут такого сверхъестественного? В тех же самых ноутбуках есть выбор, условно либо HDD на 1 Тб, либо SSD на 256 Гб за сравнимые цены.

У меня 9-летней давности ноут с 500Гб SSD. Что я делаю не так?


Цены? Ну вроде как в IT индустрии на зарплаты люди не жалуются?


(сразу добавлю, что ноут — это ThinkPad x220 и он старый не потому, что денег нету на новый :)

Цены? Ну вроде как в IT индустрии на зарплаты люди не жалуются?
Разумеется все остальные, не айтишники, а так же те, кто только начал работу и всё ещё не получает условные 1000 в месяц тоже могут купить объёмный ssd. И именно по этой причине для windows 10 рекомендуют ssd.

Лично я для себя преимуществ ssd не вижу. Ускорение загрузки раз в месяц не стоит тех денег.

Есть хорошие по железу/цене ноутбуки с комбинациями типа SSD 512Gb + HDD 2Tb


Ну и не только айтишники ноутбуками пользуются.

Ну, вообще я долго пользовался линуксами на ноутбуках — где-то с поколения thinkpad t4x. И в целом складывается впечатление, что это костыли и велосипеды. Чего только стоит, что постоянно что-то приходится вручную доконфигурировать. Есть постоянно маленькие досаждающие баги (из серии "блютуз не включается"). Танцы с установкой — uefi/legacy/secureboot. Но в целом обычно работоспособная конфигурация получается. И все относительно ровно. Но вот время работы от АКБ прям расстраивает. По сравнению с ним же под виндой. Для меня это особой проблемой не было — розетка обычно есть. Но кто-то другой может расстроиться.

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

На моем прошлом ноуте была ровно диаметрально противоположная ситуация. 5 часов автономки под Linux и 1.5-2 (если очень повезет) под его штатной Win7.
Мне было не особо интересно. Меня вполне устраивало время работы в Linux. Примечательно, что при запуске Win7 система охлаждения выходила сразу на большие обороты и почти никогда с них не уходила (в taskman при этом нагрузка по нулям отображалась).
У меня вообще постоянно были какие-то «приколы» с acpi под thinkpad. Thinkpad x280 с OpenSUSE на борту сам просыпался с закрытой крышкой, включал кулеры на максимум гудел 5 мин и потом засыпал, потом опять через какое-то время просыпался. И если это все происходило в сумке или рюкзаке — то он там жарился как в печке. Если успевал замечать что что-то не так, открывал сумку чтобы он «подышал свежим воздухом». В конечном итоге такой постоянный перегрев и привел к поломке — отвалился проц.

Мое мнение после 10 лет эксплуатации линукса на ноутах(thinkpad x серии и vaio) — для мобильного рабочего места линукс не подходит, будет какая-то фигня вылазить постоянно, вот для сервера или десктопа очень даже неплохо.

Поэтому перешел на мак потому что в нем в отличии от thinkpad, нормальное охлаждение(кулеры+алюминиевый корпус), нормальный корпус(пластик скрепит, царапается, затирается), нормальная ось(режим сна работает). При этом и мак и thinkpad x серии в одну цену. И это уже не тот старый добрый thinkpad от ibm в котором корпус был титановом-магниевый.

Все именно так, поэтому сижу на macbook pro 13
В теории можно возродить историю с thinkpad на новом уровне, но очевидно, что это будет гик продукт. И поэтому стоимость будет ого-го, а проблем надо решить массу. С другой стороны, у этих же ребят что-то получилось https://system76.com/laptops/lemur ?

Я на ситуацию смотрю под другим углом. С 2000 года поработал под кучей операционок, и винда была, и линуксы разные, и фряха с опенбсд, и маки.

И скажу прямо, когда Торвальдс начнет использовать ноут как мобильное рабочее место — эти все проблемы решаться.

Поклонником thinkpad являлся до последнего, но терпение вышло, да и сидеть на старом «трушном» железе уже проблематично, хотя и таких знаю, кто до сих пор покупает старые ibm thinkpad для работы, но это очень специфичная работа, в основном в консоли + хfce на минималках. И если до этого я всеми силами пытался избегать мака, то сейчас производители не оставили альтернативы.

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

не ради холивара, но что толку от вливаний в R&D, если ноуты получаются посредственные? Я уже у второго работодателя вижу патологическую любовь к корпоративным HP. И могу сказать, что это обусловлено совершенно не техническими причинами, а скорее тем, что раз заказываешь сервера HP, то вот тебе и ноутбуки в нагрузку. Это раз. Два — я не могу сказать, что те же хапэ ужасные ноутбуки — десктопный сегмент еще хуже, но эффективность работы на них по разным причинам сильно ниже, чем на аналогичных dell или маках. И это серьезно. Потому что ноутбук должен быть не только напичкан всякими крутыми r&d штуками и нести на себе крутой логотип крутого бренда, но и вообще быть нормальной, сбалансированной железкой. А крупным вендорам… пофиг. Они не этим берут. С другой стороны — да, есть поддержка, вероятность проблем минимальна, в отличие от безымянного Китая, ну, и всегда есть гарантия — вот была история, что у XPSок батарейка вспухает — но приходится вендору идти на попятную и менять или чинить несчастным владельцам устройство.


Так что, повторюсь, по совокупности — я тоже перешел с thinkpad'ов на мак. (((( и пока альтернатив не вижу.

Я скорее описываю тенденцию, что ноуты кроме эппла со временем становятся хуже (у «не эппл» конкуренция постоянная с китаем, и как следствие постоянно удешевление). И выходит что эппл выпуская минимально или вообще не модифицированное железо со временем просто стал лучше всех остальных. Хотя изначально эппл был в роли догоняющего.

В целом маки имеют кучу проблем, но количество этих проблем стабильно в каждой версии и не больше двух проблем за раз. Другие же производители улучшают много чего и сразу, и в целом решение хуже чем предыдущее, вот и страдает качество.
С «не эппл» — это как раз хорошо показывает линукс, я до этого постоянно пользуясь только одной x серией thinkpad-ов, при покупке нового сначала смотрел в инете что с поддержкой. И где-то первые пол года — год было печально и больно с поддержкой. И это в пределах одной серии одного производителя, а что говорить про переход между производителями и разными сериями.

r&d наверное важнее больше в мобильном сегменте и только потом эти разработки должны попадать в ноуты.

Linux нормально маки поддерживает? Или вместе с железом и софт сменили?

В смысле нормально? Я не понимаю Вашего комментария? ОКей. Давайте с самого простого — нафига на мак ставить линукс? Если очень надо — докер есть, виртуалбокс тоже нормально работает. Предположу, что Вы бескомпромиссны, мак ось вообще не переносите и хотите полностью тюнить систему сами. Ну, окей — ставьте линукс, кто запрещает-то? Оборудование у маков вполне стандартное. Ну, может какие-то специфические возможности потеряете вроде шифрования дисков. Ну, и ладно.

Речь шла о том, что железо у эппл хорошее, качественное, корпуса не скрипят и т. п.


А почему его не поставить? Если я его покупаю как просто хороший ноутбук и с радостью бы купил без ОС, если бы он стоил заметно дешевле чем с ОС. Зачем мне переучиваться на новую ОС?

Если я его покупаю как просто хороший ноутбук и с радостью бы купил без ОС, если бы он стоил заметно дешевле чем с ОС.

В случае маков такого нет и никогда не будет


Речь шла о том, что железо у эппл хорошее, качественное, корпуса не скрипят и т.

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

В случае маков такого нет и никогда не будет
С учётом того, что вам его даже по гарантии без MacOS чинить не будут (и нет, в данном конкретном случае это не прихоть Apple: у них там в MacOS костыли, необходимые, чтобы эта хрень без вентилятора не сгорела к чертям)… было бы странно ожидать скидку.
Давайте с самого простого — нафига на мак ставить линукс?

Под линуксом может быть привычнее и удобнее.


Оборудование у маков вполне стандартное.

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


Ну и на макбук 2012-го, что ли, года у меня линукс таки не встал — видео не завелось. Но я не так много времени в это инвестировал, thinkpad достаточно хорош для меня.

Я ставил на macbook pro ~2013 года, первый в общем с retina дисплеем. Именно по причине привычности. Все работало и тачбар и выход из спящего режима и wifi, но не сразу конечно. По мере выхода новых ядер все постепенно исправлялось.

У меня на старом ноуте была точно такая же ситация, но с виндой. Там в итоге ещё и SSD отваливался из-за перегрева.


Сейчас новый ноут — тьфу-тьфу, не включается.

С одной стороны, у меня есть Thinkpad T560 — там всё работает из коробки, вплоть до сканера отпечатков пальцев (насколько это понятие применимо для генты — мне ни с чем не пришлось отдельно возиться).


С другой стороны, у меня есть знакомые с макбуком, который я иногда у них беру для мелких задач. Свежая прошка 2019-го года, процессор с 6 физическими ядрами и 12 логическими. За последний месяц я брал его два раза, и оба раза он вёл себя исключительно неудовлетворительно:


  1. Надо было протестировать работу своего проекта под маком. Тесты проекта запускают 12 копий одного бинарника (по числу логических ядер) одновременно и что-то с этим делают. На своей линуксомашине я могу спокойно написать stack test и заниматься своими делами (слушать музыку, строчить комменты, сёрфать интернеты), не замечая, что там что-то в 12 потоков кряхтит. Макось от такого насилия, видимо, офигела, зависла секунд на 20 (даже курсор не двигался), потом пшикнула вентиляторами и выключилась.
    А, ну и ещё стоило больших усилий узнать, что DYLD_LIBRARY_PATH не наследуется субпроцессами без отключения SIP, поэтому пришлось прописывать симлинк на либу в /usr/local/lib (и документировать это в README). Мак точно для разработчиков?
  2. Надо было позвонить по google meet. Я почему-то думал, что под гентой оно обязательно не заведётся, и даже не пробовал зайти из-под браузера на своей машине. Только вот почему-то гуглохром под макосью при заходе на соответствующую страницу браузер наглухо вис (до перезагрузки, впрочем), так что пришлось звонить с мобильника.
    Потом я таки рискнул и в следующий раз позвонил из-под генты — всё просто работает, от микрофона-звука до камеры.
Мак точно для разработчиков?

вполне. Опять же — не предполагается, что что-то сверх-тяжелое будет выполняться на ноутбуке, но какие-нибудь легкие тесты и отладка — почему нет. У DS'ов больше бомбит от того, что у им своим GPU-оптимизированные (CUDA) приложения локально не позапускать. Этот кусок рынка яблоко реально откровенно просрало, но, к справедливости, у всех DS'ов есть мощные самосборные машинки с 3+ видеокартами для того, чтобы датасеты с kaggle обсчитывать, куда они ходят удаленно по ssh — и тут опять встает вопрос — а действительно ли локально нужно иметь мощную машину.
Ну, и еще один момент — надо понимать — мы пишем код под POSIX (ну, типа переносимый между lin/win/mac) и тогда все ок, либо надо расчехлять докер или виртуалку, т.к. мак все-таки другая операционная система.


Только вот почему-то гуглохром под макосью при заходе на соответствующую страницу браузер наглухо вис (до перезагрузки, впрочем), так что пришлось звонить с мобильника.

активно пользуюсь — google chrome, meet, hangouts, zoom, skype, telegram и пр — проблем никаких нет

Есть хорошие по железу/цене ноутбуки с комбинациями типа SSD 512Gb + HDD 2Tb
Я не отрицаю их наличие. Просто среднестатистический человек не может их купить, не больше ни меньше.

Среднестатистический человек не может или не будет в Линукс, и ?

По вашему, если у человека нет денег на ssd, то он не будет ставить себе linux? Или может быть, если кто-то поставил linux, то он может предъявить сертификат работодателю для повышения зарплаты? Гениальная логика же! Вы не допускаете, что человек может поставить linux своим родственникам например, или же не видит смысла тратить на условные 500 долларов больше, только ради того, чтобы корпорации могли писать всё более требовательный код? Речь идёт не о покупке ssd когда он действительно нужен, например для современных игр или же сборки больших проектов, здесь идёт речь о том, что ВСЕ пользователи просто обязаны обновить свой пк только лишь по тому, что в календаре уже 2020 год?
Поэтому Поттеринг разумно выжидает, пока все оставшиеся некроманты не перейдут на SSD.
Вот уж действительно некромантия, прогресс ради прогресса. Вот интересно, а использование x86 приложений, это некромания в какой степени?

Я себе недавно взял себе ноутбук — так в нём вообще нет возможности поставить HDD, только два M.2 SSD. В итоге поставил SSD на терабайт — обошлось мне это в 8 тысяч рублей, ни о каких $500 речи больше нет.

Ух-ты, я как-то пропустил момент когда терабайтники SSD начали стоить чуть больше $100! Да, теперь для HDD реально осталось только одно применение — хранить видео-файлы и бэкапы.

Я так понимаю, это qlc. Там вопросы к скорости за пределами кэша и к надежности. Tlc всё-таки две сотни стоит.

Нет, там TLC, стоят они сейчас порядка $120-130 за обычные модели, а $200 и выше — это уже топовые модели типа Samsung 970 PRO.


На самом деле, всё зависит от сценария использования. Мне не нужно копировать за раз несколько десятков гигабайт данных, поэтому на скорость за пределами кэша мне пофигу. Основной критерий был — энергопотребление, нагрев при достаточных скоростных характеристиках.

Не годится. Даже драный SMR вполне себе выдержит лет пять на полке, а вот про QLC у меня есть пара вопросов.

SMR-то выдержит, а механика?
Стрессовая нагрузка (запуск) в разделившемся на фракции гидроподшипнике может передать привет. Особенно, если на нем тоже сэкономят.

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

Только вот винт на полке не попадает ни в одну из этих категорий.

Сейчас достал 2Тб, который на полке уже лет пять лежит — завёлся наура, читается прекрасно.

И это прекрасно.
Но вы же не можете не понимать, что о совершенно другом диске этот опыт не говорит ровным счетом ничего.
Особенно если учесть, что в предполагаемом новом smr-диске начали экономить, ради чего, собственно, smr-то и завезли, и стали втихую пропихивать.


Собственно, этот-то чего сказать хотел… Спорить о надежности двух продуктов, сделанных с целью максимального удешевления… ну, то такое.

Одни из худших ssd дисков на рынке, если верить тестам выносливости.
Когда-то OCZ Vertex был худшим в этих тестах, вон валяется в развалившемся ноуте — 10 лет отработал и ещё столько же сможет =)
Да и гарантия у WD 5 лет на эти железки. Так что всё не так страшно. А данные можно и на самом надежной модели диска потерять — там как с динозавром вероятность.

Так что всё не так страшно, если в десктоп/ноутбук втыкать. В серверах может и быстро умрет.

Но да, TLC, а тем более дешевые — наименее надежные по тестам, это не новость. Хочется надежных — либо платите скоростью доступа, либо платите интелу, давно известный факт.
ocz в свое время дохли как мухи от багованого контроллера, насколько помню. WB blue просто нет доверия. Их контроллер очевидно говно, потому что у других тошибовская память умеет работать нормально, хотя сама по себе она тоже так себе. Смысл брать заведомо плохой вариант.

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

У меня OCZ отлично работает с 2011 года. Осталось ещё 98% ресурса. А от багованного контроллера умер купленный чуть раньше Corsair x128.


Но в целом надо понимать, что SSD — это штука не столько для надёжного хранения данных, сколько для ускорения работы с данными. Необходимость бэкапов никто не отменял.

Да сейчас вполне надежно уже все. Почему wd blue и смотрится так аномально. Он на 3d nand (хоть и от тошибы), не dram-less какое-нить поделие копеешное, а так плохо выступает. Просто привыкли, что ssd как правило выходят далеко за границы заявленного ресурса. В основном конечно самсунги приучили.

А чем dram-less не угодил? Для ноутбуков вполне нормальный вариант из-за более низкого энергопотребления. А по скорости особой разницы нет.


Ну а если у вас серьёзные нагрузки, то, скорее всего, у вас уже не ноутбук, а рабочая станция.

> Смысл брать заведомо плохой вариант.
400 TBW для террабайтника — не самый плохой вариант, в общем-то. Особенно, когда не хочется нести интелу 18+ тысяч за десктопный ssd.
А все остальные — те же сорта дерьмеца, про которые можно сказать, что когда-то там в каком-то году они или сыпались, или тормозили.

> А в серверах надо использовать диски для серверов
В серверах используют то, что на данный момент в конкретном данном сервере оправдано. И у террабайтных консумерских ssd на 1TB область применения в серверах сейчас есть, как была и у 512GiB, которыми забиты все бюджетные хостеры — и никто не жалуется.
400 TBW для террабайтника — не самый плохой вариант

По нынешним меркам плохой, если диск умирает ровно на этих 400. По тестам 250Гб версия сдохла после 82тбайт записи из 100 заявленных. Это позорный результат.

А все остальные — те же сорта дерьмеца

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

В серверах используют то, что на данный момент в конкретном данном сервере оправдано.

Естественно сервера разные бывают, только как правило под этим подразумевают что-то серверное по нагрузкам, для чего консьюмеровские диски никак не катят. Базы на них крутить себе дороже. Они свои скорости в таких областях не могут обеспечить, ибо контроллеры у них для других целей.
> По тестам 250Гб версия сдохла после 82тбайт записи из 100 заявленных.
Так пусть в гарантию отнесут, у 256 гарантия до 150 TBW, у террабайтника до 400 распространяется, в чём проблема?
У них SunDisk ultra 3D, который является тем же диском с другой наклейкой, 500+ надолбил. А у 3dnews WD blue 700+ отмотал тот же.
Бестолку судить по одному тесту на единственном сайте, тем более, когда есть совершенно противоположные мнения.

А самсунг привез 256Gb-платы в корпусе от террабайтника с серийником от террабайтника. Их тоже не покупать из-за одного случая?

> только как правило под этим подразумевают что-то серверное по нагрузкам
Не знаю, что у вас там за «правила», но серверов, которые обслуживают высоконагруженные БД в мире — единицы процентов (если не десятые процента). Девелоперских/тестовых серверов, хомячков с лампой на сотню тысяч запросов в день и файлопомоек — в разы больше (буквально). И там дешманские ssd отлично прижились. Потому что через 5 лет ты их тупо выкидываешь и меняешь на х4 по объёму. А помирать? Да нет, не помирают массово, иначе всякие hetzner-ы и OVH уже давно разорились бы.
Понятное дело, что есть задачи, в которых десктопным ssd не обойдешься — но их количество не позволяет даже близко заявлять, что чему-то там где-то там не место.
Я выше уже озвучивал, что нет смысла смотреть на TBW, если вы покупаете один единственный диск в свой личный комп.
Просто выбираете подходящий по цене диск от известных производителей — OCZ, WD, Corsair, Samsung, подставить_своё. Главное, чтобы была российская гарантия и возможность достучаться до неё.
Если задача более сложная и есть деньги — всегда покупаю Intel (впрочем, единственное место, где я купил intel лично себе — домашний сервер, ssd под систему).

У любого производителя бывают неудачные партии с браком, так что вероятность потерять данные — всегда 50%, если диск один. А даже самая минимальная тысяча циклов перезаписи для личного ПК — огромный ресурс, пара десятков лет минимум с учетом TRIM-а. По сути самые первые SSD из условно «современных» (2008-2010) ещё не начали массово умирать из-за израсходования ресурса перезаписи, если речь про ПК с обычными задачами.

Ну у меня за 73290 часов работы по данным контроллера суммарно записано порядка 22 ТБ данных. SSD не жалел совсем: и своп на нём, и торренты. Так что 400 TBW для меня — это достаточная величина.

Есть и попроще модели, типа 128+512. Я к тому, что HDD на домашних или рабочих компах ещё не редкость.

все вы делаете не так — странно иметь дисков менее чем не 10Т, а это уже не SSD (те я использую только в качестве кэша разве для ZFS)…
У вас в 2020 году HDD на десктопе?

У меня на десктопе SSD на 240 гигабайт и два харда на два терабайта в RAID1. SSD для разработки, / и почти всего ~, кроме папок с говорящим названием storage и music. Зачем мне почти полтерабайта музыки хранить на SSD, в конце концов?

Windows NT появился в 1993 году. Windows 2000 — в 2000.
И там уже была вполне вменяемая система запуска сервисов и довольно функциональный ServiceControlManager.
Неужели было настолько сложно взять это удачное решение (SCM API) за основу?

У него уже тогда было довольно много очевидных преимуществ над той системой, что тогда была в линуксе, расширенный контроль системы над состоянием сервисов и т.д.
Он был настолько успешным, что появился nssm с характерным названием.
И по сей день отдельные виндовые сервисы (mdt monitor, например) при фейле зависимостей возвращаются с кодом 0 и не перезапускаются вне зависимости от настроек SCM.
Ну а чтобы собственный сервис добавить в SCM нужно либо перекомпилять всё, либо врапперы использовать. В общем, оно тоже не сахар, это ваше SCM API.

А, ну и я в порыве графоманства забыл ответить на вопрос.
Сервис в винде — это отдельно-хитрый бинарник со своим энтрипоинтом и прочим. В линуксах демоны просто детачатся от терминала, в остальном это точно такие же бинарники, как и везде. SCM полагается на то, что логику управления сервисом будет реализовывать сама бинарь, sysvinit возлагает эту обязанность на инитскрипты, так как внутри бинари это будет привязано к определенной инит-системе, что противоречит духу платформы.
внутри бинари это будет привязано к определенной инит-системе, что противоречит духу платформы.

Это генерирует много ненужных костылей вокруг запуска этих скриптов.
И потом использование SCM вполне может быть опциональным — есть же виндовые программы, которые могут запускаться и как сервис, и как обычная программа.
Ну и да, совершенно необязательно повторять все косяки Win SCM. Я говорю о самой структуре управления сервисами, когда часть, отвечающую за репорт состояния сервиса, берёт на себя сам сервис.
репорт состояния сервиса

Не в курсе чё там в SCM, но в systemd какой-то репорт таки есть через функцию sd_notify (впрочем, это таки требует линковки с libsystemd)

Не требует. sd_notify() всего лишь пишет посредством send() в открытый UNIX socket, номер которого содержится в переменной среды NOTIFY_SOCKET, то что он пишет вполне текстовое, типа "READY=1\n" или "STATUS=Failed...\n".

> когда часть, отвечающую за репорт состояния сервиса, берёт на себя сам сервис.
Так а нет понятия «сервис» в этих ваших линуксах. У демонов детачим консоль, а сервисы — это демоны с каким-то дополнительным функционалом для работы с инит системой (какой именно?) И через что взаимодействовать будем — dbus, али ещё что? (upd: чуть выше зашла речь про сокеты, и это действительно был вариант)
В 90-х всего этого попросту не существовало, вероятно поэтому и ограничились скриптами.
Первое впечатление о systemd было неоднозначным, было много негатива, а порой даже агрессивных выпадов в духе да как они могли покуситься на святое, было много разборов багов и неожиданных поведений во вполне ожидаемых событиях, но почему-то systemd считал по другому.
Решился в итоге на обновления виртуалок с debian 7 только спустя год после выхода 8ки jessie, и в принципе не пожалел. И следом обновил совсем уж старые centos6 до centos7. Разницы конечно глобально не заметил, upstart на центоси и runit на дебиане функции свои выполняли исправно, единственное, что стало плюсом, одинаковый конфиг сервисов на любой ОС. Хотя понравилось что ушли от своеобразной системы логирования у runit, всё стало логироваться в syslog.
Но как я понимаю, что это до поры до времени, journalctl пока не повсеместно используется, пока в 10м дебиане и центос8 логи пишутся по старинке, но вот в домашней федоре уже просто грепом по файликам не пройтись, и это не очень нравится. Конечно, дело привычки, но всё же.
По стабильности, за 4 года столкнулся всего два раза что сервисы переставали отвечать на команды, не запускались, не останавливались. Оба раза помогло systemctl daemon-reexec, без дорогостоящей перезагрузки всей системы.
Из мелочей — не работает опция CapabilityBoundingSet, например CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права, решилось установкой через setcap непосредственно на бинарник.
И в итоге — по моему опыту использования как раз основная претензия к journalctl, если остальные компоненты systemd занимаются ровно тем, чем должны по идеологии PID1, на мой взгляд как раз логирование выходит за эти рамки.
в домашней федоре уже просто грепом по файликам не пройтись

Это как раз просто — journalctl --since today | grep ... — ничем не хуже, даже в чём-то лучше (с учётом других опций).


Проблема с journald (одна из) совсем в другом, на самом-то деле — он пишет всё что есть, нет возможности фильтрации до записи (кроме как по уровням), со всеми неудобствами (очень много мусора), но редиска Поттеринг сопротивляется этому всеми фибрами, утверждая что писать нужно всё без исключений (даже тонны мусора), а фильтровать исключительно при просмотре.

— Проблема с journald (одна из) совсем в другом, на самом-то деле — он пишет всё что есть, нет возможности фильтрации до записи (кроме как по уровням), со всеми неудобствами (очень много мусора)…
Ну вот, собственно, это и причиняет неудобства. Я не совсем корректно выразился, что хотел сказать. С этим разобрался, конечно, с флагами, но то что пишется всё в одну кучу, не айс. Смешались в кучу, люди, кони, и всё другое. Это нехорошо. И всё равно, даже есть такая возможность, на основной процесс, который рулит всей системой, вешать логирование неправильно, причём без права разделения.
И всё равно, даже есть такая возможность, на основной процесс, который рулит всей системой, вешать логирование неправильно, причём без права разделения.

на самом деле правильно. Вот, предположим, запись в лог у вас блокирующая. Место на диске кончилось. Ваши действия? Ждать пока логротейт придет?


Кстати, в убунтах этих ваших — выхлоп journald бережно rsyslog'ом режется на файлы и складывается в текстовом виде в /var/log/*.log (auth, syslog etc.). Т.с. для легаси админов, которые умеют только в текстовые файлики. Все для Вашего удобства, т.с.

на основной процесс, который рулит всей системой, вешать логирование

Никто там ничего не вешает.


root       46465  0.0  0.7 133572 64680 ?        Ss   May28   0:16 /lib/systemd/systemd-journald

Это отдельный процесс вообще-то.


Запустите systemd-cgls — увидите много интересного.

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

если подумать, то он прав...

Подумайте об устройствах типа RPi с SD-картами, где какой-то сервис пишет неотключаемый дебаг в журнал минимум раз в секунду, причём на уровне info вместе с иногда (и очень редко) нужными сообщениями.


Или о системе где сотня сервисов и каждый (ре)стартует посредством таймеров раз в несколько секунд — зачем мне знать что они start/stop, если мне гораздо важнее знать как раз наоборот — что кто-то этого вовремя не сделал?


Или о сервисе который вдруг выдал сотню тысяч строк дебага, ушедшего в журнал и убившего (за счёт ротации) всё остальное что там было?


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


Ну и наконец… Есть всё-таки разница, фильтровать вывод с чего-то размером в 100 мегабайт или 10 гигабайт, особенно если в последнем случае полезной информации не более чем 100 мегабайт, но вам нужен диск побольше просто ради мусора (и хорошо если это не SSD/SD).


Что примечательно — на гитхабе несколько многолетних веток на эту тему, ясно что фича нужная и полезная, но позиция Поттеринга — "я не убежден что это нужно". Ушли буквально годы чтобы в сервисах можно стало перенаправлять вывод в файлы или сокеты (вместо journald), на фильтрацию, наверное, вообще уйдут десятки лет… И проблема совсем не в том чтобы это сделать (pull requests были) — проблема в позиции "это неправильно, нужно писать всё и не давать никому выбора". Чем-то напоминает djb с его errno...


Если почитать его мнения на этот счёт — да, в идеальном мире это должно делаться на стороне сервиса — и фильтрация, и прочее, journald не может знать что важно а что нет, но увы, мы живём в реальном мире и некоторые (особенно очень древние) сервисы не переписать и ненужные логи не отфильтровать, разве что посредством внешнего приложения типа multilog, что вносит другие проблемы.


PS: Извините, наболело. По факту, это единственная насущная проблема связанная с systemd… всё остальное, при всех недостатках, всё же сильно перебивается достоинствами.

А повесить свой фильтр на свой сокет, писать в него, а он уже после фильтрации будет в журнал?

Если вы не желаете чтобы ВСЁ писалось на диск/флешку — можно легко отключить запись бинарных логов journald на non-volatile storage и хранить логи только в оперативной памяти. Мне мнится, что на типичном десктопе с или raspberry pi почти всегда логами с прошлых запусков системы можно пренебречь. Опционально можно копировать логи из journald в какой-нибудь классический syslog демон, его силами фильтровать ненужное, а потом писать что хочется, куда хочется и как хочется. Я лично, к примеру, на серверах локально пишу таким образом нужные кусочки логов. И доволен аки слон.
Кстати, у journald эта опция по дефолту выставлена в "Auto", при этом значении на диск логи пишутся в случае существования пути /var/log/journal/. Если пути нет — пишутся только в память. Поэтому на всяческих rpi можно просто сразу сделать rm -rf /var/log/journal и забыть о проблеме.


Ну и напоследок хочу заметить: мне кажется крайне неправильно считать journald этакой плохо спроектированной и недостаточно фичастой заменой классическим syslog демонам или специализированным решениям для сборки и консолидации логов на отдельной хранилке. Воспринимайте journald как нечто, что собирает в одном месте выхлоп от всего, что его в принципе производит, заодно авторитетно добавляя поля типа pid/name источника. А дальше это нечто позволяет делать с собранным то, что вам нужно + даёт возможность посмотреть все логи единым полотном, что нередко очень и очень удобно.

CapabilityBoundingSet=CAP_NET_ADMIN CAP_IPC_LOCK CAP_SYS_NICE не выдаёт нужные права

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


Для выдачи прав есть AmbientCapabilities=, например:


AmbientCapabilities=CAP_NET_BIND_SERVICE

Это не в systemd дело, просто подсистема capabilities так работает.

Из всего сказанного понятно, что главным недостатком BSD like скриптов, sysvinit,…, является то, что они написаны не Поттерингом.


Оно и верно, зачем изучать разумное и совершенствовать его? Ведь надо создавать новое, отрицать старое, мешать в одну кучу udev и system start/stop, нарушать принципы, вести народ в будущее.


У нас нет авторитетов! Мы делаем новую жизнь, нам понятен формат winini файлов.


Ура, товарищи!

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

Зря вы так думаете. Разумеется, rc скрипты поставляются разные, некоторые разработчики не уделяют должного внимания start/stop скриптам, поставляемым в составе их продуктов. Так было всегда, это примерно так же, как поставлялись m4 скрипты в составе библиотек, когда автор просто копирует чужие скрипты и слегка перерабатывает их под свои нужды (при этом источник выбирается не всегда самый правильный).

Однако сообщество, вместо того, чтобы написать автору какой-либо библиотеки предложение по улучшению в их скриптов, решило что лучше отдать все на откуп pkgconfig (который, кстати тоже глючит немерянно).

Так вот, когда мне приходится работать со сторонними демонами, я либо отлаживаю поставляемые в их составе rc скрипты, либо создаю для них новые. Всегда стараюсь написать автору и предложить решение существующих или потенциальных проблем.

И это нормально, это же OSS сообщество, где люди помогают друг другу, а не враждуют.

Однако сейчас о такой кооперации остается только мечтать. Общество становится все более токсичным и люди скорее склонны отрицать старое разумное, ввиду невозможности понять, и создавать альтернативы, которые кстати зачастую убивают лучшее и привносят новые ошибки. Так было во время введения pkgconfig, так было во время создание systemd, так же будут поступать с Autoconf, Automake путем их замены на CMake, ninja+meson,…

Но я надеюсь на то, что OSS сообщество не превратится в террариум.
Посмотрите на портянку rc скрипта от GitLab. Я, например, адаптирую его под Slackware и не жалуюсь. Это нормально.

Full disclosure: я терпеть не могу systemd. Но статья понравилась, хоть и написана очевидно предвзято, но автор и не скрывает. Поэтому просто немного прокомментирую статью.


начиналось как просто PID 1 и стала тем, что я бы назвал middleware современного дистрибутива Linux

И это плохо само по себе. Тем более, что опыт показывает, что в этом нет реальной необходимости: у меня Gentoo, причем даже не на OpenRC а на Runit, и при этом много лет используется udev (точнее eudev) и вот на днях перешёл на logind (точнее на elogind). Как видите, нет большой проблемы выделить полезные и нужные компоненты из systemd — или, говоря иначе, нет и небыло реальной технической (в отличие от политической!) необходимости изначально слеплять их в одно целое.


В атмосфере беспорядочного хаоса было предприняты несколько попыток решить проблемы sysvinit:

Вы забыли упомянуть некоторые более достойные альтернативы, вроде того же OpenRC, Runit и S6 — а без этого обзор, мягко говоря, не даёт реальной картины.


Но на сегодня самой известной альтернативой (кроме systemd) является, пожалуй, Upstart.

Да неужели?!
image


Это и произошло. Debian Jessie вышла с systemd в качестве менеджера системы, и вслед за Debian …

… появился Devuan, который "Debian без systemd". Википедия говорит, что есть 53 дистрибутива без systemd. Я это к тому, что из Вашего описания складывается впечатление, что последние бастионы сопротивления пали на дебиане, и везде воцарился systemd… так вот, это не так.


С целью решить эти проблемы и был представлен journald:

Честно говоря, даже не хотел это комментировать — его не пнул только ленивый, и даже фанаты systemd на него плюются. Впрочем, чего молчать-то: большая часть "решённых" проблем не является реальными проблемами на практике (или уже имеют отличные решения в runit/s6), зато те новые проблемы, которые он создал взамен старых — весьма реальны.


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

Это просто слова. А факты можно увидеть в базе CVE: 56 записей.


Платформа systemd, на самом деле, гораздо проще традиционного Linux, потому что она объединяет системные объекты и их зависимости в юнитах с простым синтаксисом конфигурационных файлов.

Это бред, уж простите меня за прямоту. Юнит-файлы systemd проще rc-скриптов sysvinit — безусловно. Но сам systemd крайне сложен, и ограничить его изучение синтаксисом unit-файлов можно ровно до первой проблемы… а потом придётся разбираться с самим systemd, и это будет намного сложнее отладки rc-скриптов sysvinit, OpenRC и тем более run-файлов Runit.


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

Посмотрите на Runit или S6, чтобы не было потом стыдно за такие заявления.


число багов довольно мало для такого ключевого компонента ОС

1200+ issues, из них 89 открытых багов… для такого ключевого компонента ОС — это просто неприемлемо!


Для сравнения, у OpenRC 61 issue, из них поиск по слову bug выдаёт 14 (и не факт, что всё это реальные баги OpenRC, а 89 вышеупомянутых багов systemd имеют метку баг поставленную разработчиками systemd, т.е. это признанные баги). Про Runit сказать сложнее за отсутствием его на гитхабе, но насколько мне известно багов в нём нет. У S6 сейчас открыт 1 issue, и да, это баг — но баг сборки.


В целом, Ваши слова являются типичным проявлением Стокгольмского синдрома.


это новая эпоха в истории экосистемы Linux

Ага. Позднее её назовут "тёмные века". :)

рунит c 2014 года не обновляется, конечно стабильность есть. Но иногда нет уверенности как рунит поведет себя в паре системд, в проде как-бы нужна стабильность, поэтому рисковать нет особо желания. Поттеринг реально опасный тип, поэтому и приходится на нативный в дитрибутив запуск переходить. Моя бы воля, на дебиане7 бы до сих пор сидел, но ядро уже по тех требованиям не подходит. Почти смирился уже )

Нормально он себя ведёт. Если его просто запустить и больше средствами systemd не трогать.


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


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

потому что всё, что он делает — это запускает докер, а всё остальное на этом сервере запускается внутри докера.

это потому что у Вас нет специфических задач. Скажем, такой пример. Лежат файлы на NFS. Вы можете его подмонтировать как systemd mount — это правильно (либо сделать как-то иначе, но лучше не стоит). Далее выясняется, что докер контейнеры не умеют в зависимости. Вы их оборачиваете в системди юниты и выстраиваете цепочку перезапуска. Либо тащить nfs клиента в каждый докер образ (фу). Если же цепочку не выстроить — будет очень простая история, что протекут какие-нибудь дескрипторы, где-то внутри что-нибудь отвалится и вероятно, что Вы даже про это не узнаете, разве что по каким-то косвенным признакам.

Вы берёте сложный инструмент и пытаетесь решить простую проблему сложным способом, раз уж инструмент даёт такую возможность. А в реальности всё намного проще: сетевые диски нужно монтировать до запуска всех сервисов, включая докер. И, разумеется, их не нужно отмонтировать в процессе работы. Всё, проблема зависимостей решена, точнее её просто нет. Просто представьте себе, что этот сетевой диск — это volume на AWS. Да, он сетевой. Нет, он есть всегда, доступен сразу при загрузке, и отключать его в процессе работы никто не будет — потому что он притворяется локальным диском, как и должно быть. (А если будет — то он знает, что делает и какие будут последствия.)

Только вот, во-первых, у вас не aws, во-вторых, я и не предлагаю его отмонтировать на ходу. Я ещё в здравом уме. Но вот залипнуть клиент nfs вполне может. Сетевые проблемы, скажем. И тогда придется перемонтировать. Дальше — по моему сообщению.
Т.е. по существу — вопрос в том как разбита система на уровни и кто за них отвечает.

Если он залип в процессе работы — это уже никакого отношения к зависимостям между сервисами не имеет, потому что в этот момент зависящие от NFS сервисы уже давно запущены (и тоже залипли на попытке I/O). Перемонтирование в этих условиях не должно приводить к перезапуску зависимых сервисов, они просто штатно получат ошибку от ядра и обработают её как для них это правильно — повторив операцию I/O, например.

обработают её как для них это правильно — повторив операцию I/O, например.

не будь запущены в докере, кек

Но вот залипнуть клиент nfs

ЕМНИП, 20+ лет назад эту проблему эффективно решал amd и всё такое.

Вот не факт, что всё надо монтировать на этапе загрузки по сути. Не все сервисы должны стартовать автоматом, а держать маунт удалённой ФС на всякий случай — чревато

Вы правы. Всегда можно усложнить постановку задачи до такой степени, что без сложного инструмента с ней не справиться. Но, если честно, как часто лично у Вас на практике возникала такая ситуация — есть сервис, который не должен запускаться при загрузке сервера, сервису нужен NFS, который так же не должен монтироваться при загрузке сервера, и при этом есть реальная необходимость автоматически подмонтировать NFS в момент, когда админ ручками запустит сервис? Мне вот ни разу.

"Не должен монтироваться" — это просто соображение рациональности по нескольким критериям в том цисле уменьшение области воздействия потенциальных уязвимостей.

Вас, как и меня будут дизлайкать. Это нормально. Если вы не в секте, то будет так.

Проблема не в том, что кто-то в секте, а кто-то нет. Г-н powerman выказывает свое личное мнение, через призму своего личного искажения реальности.


а потом придётся разбираться с самим systemd, и это будет намного сложнее отладки rc-скриптов sysvinit

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


  1. как правило с systemd проблем нет? Вот пускай г-н powerman приведет хотя бы несколько проблем, когда проблема была в systemd. Тогда и подумаем насколько это сложно отлаживать
  2. уже рассказали как init скрипты (классические) не умеют отрабатывать исключительные ситуации. Ой, а они у нас отсутствуют, просто потому что случаются 1 раз в 1000 лет? Ну, мы же знаем — рвется, там где тонко, и попросту можно проблему не заметить, а данные, например, уже в кашу
  3. разбираться со спецификой init скриптов — то еще удовольствие. Это примерно как восстанавливать работу "макаронного кода" с непонятными зависимостями. Не говоря уже о том, что у каждого мейтейнера, у каждого софтодела и каждого дистрибутива свой взгляд на то, как должен выглядеть инит скрипт. Да, вроде бы на старте нужно только знание баша, но это примерно то же самое, что и утверждать, что в машинных кодах можно писать сложные современные многокомпонентные системы (спойлер — нет)

Позднее её назовут "тёмные века".

вообще пять. Апплодирую стоя.

Спасибо за высокую оценку. Но Вы снова противопоставляете systemd init-скриптам, а я говорил о Runit и S6 в первую очередь. Почему, Вы думаете, я упомянул, что использую Runit вместо OpenRC в Gentoo — при том, что это не является поддерживаемым подходом в Gentoo и поддерживать его мне приходится самостоятельно? Именно потому, что sysvinit — это однозначно неприемлемо. OpenRC всё-таки решил многие проблемы sysvinit, но лично я предпочту сам поддерживать загрузку системы на runit чем иметь дело с init-скриптами, пусть даже OpenRC.


Что касается "проблем с systemd" — их на данную секунду примерно 589 (открытых issues не являющихся фиче-реквестами). На самом деле меньше, конечно, часть из них не звучат как проблемы, но всё-равно их порядка полтыщи… и это спустя 10 лет развития проекта. Как по мне — это чётко показывает тенденцию, что проблем дофига, и с годами их становится больше, а не меньше. Что абсолютно неудивительно для проекта такой сложности.


чтобы перетянуть неспециалиста

Мимо — я не верю, что про systemd будут что-то читать "неспециалисты", это слишком узкоспециализированная тема для неспециалистов.


P.S. "свое личное мнение, через призму своего личного искажения реальности" — в целом это, конечно, так и есть. У всех так, я не исключение. Но, обратите внимание — я своё искажение подтвердил кучей ссылок на пруфы, а Вы?

Что касается "проблем с systemd" — их на данную секунду примерно 589 (открытых issues не являющихся фиче-реквестами). На самом деле меньше, конечно, часть из них не звучат как проблемы, но всё-равно их порядка полтыщи… и это спустя 10 лет развития проекта. Как по мне — это чётко показывает тенденцию, что проблем дофига, и с годами их становится больше, а не меньше. Что абсолютно неудивительно для проекта такой сложности.

ну, давайте еще линукс отрицать. Сколько там ишью? Много? Ой, какой линукс плохой. Срочно меняем ядро и мигрируем на более компактные операционные системы. Да, я передергиваю.


Runit и S6 в первую очередь.

я допускаю, что есть применения, куда systemd не очень пихать. Например, у вас какой-нибудь встроенный линукс и тупо нужно экономить память на всем. Но сервера и десктопы? Может все-таки просто признать, что мир изменился, а ты отстал и пора адаптироваться? Иначе это реально похоже на юношеский максимализм. Или донкихотство

Да, сервера и десктопы. У меня именно десктоп на Runit, примерно с 2003. И сервера на Runit, самые обычные, с тех же времён до сегодня (хотя сегодня я чаще беру первую попавшуюся убунту, ставлю на неё докер, включаю автоматическое обновление, и больше про неё почти не вспоминаю… такие времена, disposable stateless сервера, disposable stateless сервисы…).


И я не спорю, что мир изменился. Я там выше в комментариях писал, что у меня на серверах systemd (правда там кроме systemd и докера больше ничего), но ещё, если поискать, у жены Debian на systemd (который по факту администрирую я). Тем не менее, на важных для меня системах (и первая из них это как раз мой десктоп!) этой гадости никогда не будет, там будет либо Runit либо S6 — потому что они простые и надёжные, и с моей точки зрения для компонента отвечающего за загрузку системы и управление всеми сервисами критично только это — простота и надёжность. SysVInit был простым… некоторое время, пока не начали писать портянки в init-скриптах… и никогда не был надёжным. Systemd никогда не был простым и никогда не будет надёжным из-за своей сложности и попытки решить слишком большое количество очень разных проблем.


Так что это не максимализм (как я уже упоминал, в моём окружении попадается systemd и я спокойно к этому отношусь) и не донкихотство (я не один такой "псих", список из 53 дистрибутивов без systemd и жаркие споры о systemd всё время его существования это подтверждают) — просто я чётко понимаю что мне подходит а что нет, и почему именно так.

не донкихотство (я не один такой «псих», список из 53 дистрибутивов без systemd и жаркие споры о systemd всё время его существования это подтверждают)
Как раз тот факт, что вы с придыханием упоминаете не количество миллионов людей, которые пользуются Linux, а количеством дистрибутивов — как раз и указывают на то, что это донкихотство.

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

Вы забываете, что любая простота и надёжность runit сразу закончится за его пределами. И где то ту сложность, что вносит systemd, рано или поздно надо будет добавить на другом уровне… А дальше уже кто как любит — размотать ответственность по площади, или сконцентрировать в одном месте.

Только происходить это будет у тех, кому данная сложность действительно нужна, а не у всех сразу.

Где сложность systemd? Он у вас ломался (вообще, постоянно или хотя бы иногда)? Или это нытье в тренде "давайте поноем"?

Несколько раз были проблемы с systemctl suspend, какие воспроизводились в особой фазе луны. Подробностей уже не помню.

Т.е. это было на десктопе? Просто на серверах suspend не нужен, кмк

Вы провокатор )
В хорошем смысле.
Вы же понимаете, что Вы огульно обвинили системди в грехе, к которому он мог вообще никакого отношения не имеет? Ну, не знаю — кривая acpi таблица, какой-нибудь криво написанный драйвер и все такое. А виноват почему-то systemd-suspend.
Конечно, я Ваши эмоции прекрасно понимаю. И я бы тоже расстроился и послал систему такую к лешему. Но на тех же серверах и спектр оборудования существенно более узкий, и гарантии надёжности другие. В отличие от десктопа. Поэтому "имеем, что имеем". А если не хочется проблем… на десктопе… То надо сидеть под маком или виндой. Хотя… Там своих нюансов хватает.

Ну, не знаю — кривая acpi таблица, какой-нибудь криво написанный драйвер и все такое.
В этом случае, проблема должна была бы воспроизводиться каждый раз, либо только на конкретном ядре.
Поэтому «имеем, что имеем». А если не хочется проблем… на десктопе… То надо сидеть под маком или виндой. Хотя… Там своих нюансов хватает.
Там будут свои проблемы, при этом там я их решить точно не смогу.

Мне показалось, или в соседней ветке Вы говорили, что systemd особенно важен на десктопах, потому что там всё сильно сложнее чем на серверах… а теперь что же получается, что на серверах systemd не нужен ибо там всё просто и запустить докер можно и без systemd, а на десктопе systemd нельзя обвинять в проблемах потому что там всё слишком сложно? :-D

Systemd особенно важен на десктопах, но, сам по себе, к сожалению, не всегда может решить проблему — особенно с суспендом. Тот факт, что у кучи народу суспенд-таки работает правильно (у меня, в частности) — хорошее указание на то, что systemd может быть и в той проблеме, в которой его обвиняют, и не виноват.

Вот если бы человек на одном и том же железе использовал systemd и у него были проблемы, а потом перешёл на runit — и они бы исчезли… тут да, можно было бы говорить о чём-то.

А Вы забываете, что в большинстве случаев нужда в этой сложности может просто не возникнуть. Я на Runit больше 15-ти лет, и за это время такие ситуации возникали один-два раза… и каждый раз решались намного меньшей сложностью, чем приносит с собой systemd.

Будьте последовательны, коллега.
Выкиньте Линукс нафиг. Он же сложный! Я про ядро с драйверами. Сколько там строчек кода? Сколько там уязвимостей? Сколько утечек памяти? А эффективность работы линукса и софта под него с ОЗУ — это притча во всех языцех.
Выкиньте гуй — чем вы там пользуетесь? Gnome? Kde? Да пофиг. Это же тоже страшные вещи, которые нагибают всю остальную систему и заставляют использовать навязанные ими шаблоны!
Ну, так что? Только хардкор — миниядро и оболочка бизибокс. Здесь должен был быть копипаст про Мытищи и старую школу.


/Это стёб, если что/

Вы не поверите… но всё примерно так и есть.
Линукс действительно очень сложный, но, к сожалению, OS Inferno и Plan9 так и не взлетели, хотя они дают примерно тот же функционал но на порядок проще. Так что линукс — только потому, что реальный выбор между ним, маком и виндой, а не потому, что он самый простой и элегантный.
Ядро я собираю самостоятельно, и лишние драйвера и фичи в него не входят.
Насчёт уязвимостей — пока была возможность ядро собиралось с GrSecurity/PaX, это сильно ослабляло проблему безопасности.
Притча про работу с ОЗУ как-то прошла мимо меня — Вы о чём конкретно?
Gnome/KDE у меня действительно нет, у меня Fluxbox и 24 виртуальных десктопа, в каждом из которых по одному full-screen приложению — и это невероятно удобно (почти все друзья посмотрев сделали у себя так же).
Бизибокс штука тоже классная, но не на десктопе, а в контейнерах с Alpine.


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

у меня Fluxbox и 24 виртуальных десктопа, в каждом из которых по одному full-screen приложению — и это невероятно удобно

Так же делаю, только у меня их не 24, а 9 и не fluxbox, а dwm,
При этом использую 4-5 десктопов, так как браузер, а все остальное в терминале с tmux.

Ну вот я вместо tmux просто запустил в большинстве из этих 24-х urxvtc. Переключаться в нужный по Alt+Fx и Alt+Shift+Fx удобно, плюс на неиспользуемые Win-кнопки настроил переключение на следующий/предыдущий и между двумя последними виртуальными десктопами.


Плюс при загрузке машины во всех 24-х сразу запускаются нужные приложения — мессенджеры, браузер, почта, mc, терминалы, подключения по ssh к серверам, просмотр логов, etc.

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

Странно, я как-то по наивности думал, что это как раз норма. Ведь инструменты усложняются для того, чтобы взять на себя массу работы, которую до того выполнял пользователь, т.е. человек. Делать эту массу работы вручную из одного лишь мотива «так я всё контролирую» — вряд ли это можно назвать нормой. Это всегда было выбором относительно небольшого числа людей. И в случае с systemd, замечу, никто не отбирает у этих людей возможности «контролировать» систему, используя старые инструменты. Берите Gentoo, берите Slackware, да хоть свой дистрибутив собирайте на здоровье.

Никто не предлагает делать вручную то, что могут сделать инструменты. Но это никак не связано с обязательным увеличением сложности этих инструментов — просто бывает один сложный инструмент или десяток простых, но в конечном итоге делают они одно и то же. А ещё бывает так, что отдельному пользователю просто не нужны 100500 фич напиханные в один сложный инструмент, ему нужно всего 6 фич, которые ему могут предоставить 4 простых инструмента.

Решение задачи с помощью десятка инструментов по определению требует больше движений и манипуляций, чем решение этой же задачи одним инструментом.

Л — логика. Количество движений не зависит от количества инструментов.


Нет никакой разницы между тем, чтобы почитать доку на systemd и узнать, как называется необходимый параметр в unit-файле, и тем, чтобы почитать доку на отдельную утилиту, которая делает то же самое, что этот параметр в юнит-файле, и написать запуск этой утилиты в run-файле. Количество читаемой документации и набираемого текста в обоих случаях — в идеальных для systemd условиях — будет одинаковым.


Но условия для systemd далеки от идеальных — вся дока на runit и идущие с ним в комплекте утилиты — это капля по сравнению с морем документации на systemd… и вовсе не потому, что в runit отсутствует важная документация или доку на systemd писал графоман, а потому, что кучка простых инструментов обычно получается намного проще одного сложного, даже при сравнимом функционале. Но сложные инструменты тяготеют к feature bloat, что только увеличивает сложность их использования (включая поиск нужного в документации) в абсолютном большинстве кейсов, в которых эти лишние фичи абсолютно не нужны.

Количество движений не зависит от количества инструментов

Вообще-то зависит. Конкретный пример: чтобы чрутнуться без systemd, нужно ввести целый ряд команд, задействовав минимум 2 утилиты (mount, chroot), чтобы чрутнуться с systemd — достаточно 1 команды (systemd-nspawn)

Количество читаемой документации и набираемого текста в обоих случаях — в идеальных для systemd условиях — будет одинаковым

Чтобы написать юнит, нужно прочитать документацию по юнитам. Чтобы написать скрипт запуска, нужно изучить целый язык программирования — bash. Что сложнее — очевидно.

Очевидно, что Вы передёргиваете:


  • Написать юнит мало, его надо ещё положить в правильный каталог и запускать/перезапускать правильными командами. Для этого документации придётся прочитать немного больше.
  • bash учить не нужно, к сожалению — его и так все знают, потому что без него жить не получается вне зависимости от наличия или отсутствия systemd. Если бы не этот "маленький" нюанс — то я бы согласился.
Написать юнит мало, его надо ещё положить в правильный каталог и запускать/перезапускать правильными командами. Для этого документации придётся прочитать немного больше.

Серьезно? Это прямо высшая математика? Но вот с "традиционными" системами инита тоже надо знать, куда класть стартовый скрипт сервиса и как его назначать на разные ранлевелы. Баш на баш? Только в случае системди Вы вынуждены это знать, как азбуку. Т.к. это стандарт. Нравится Вам это или нет. А в случае runit — изучать заново.

Написать юнит мало, его надо ещё положить в правильный каталог и запускать/перезапускать правильными командами

Верите, нет, но чтобы найти каталог с юнитами, я не читал документацию, нашёл просто серфингом в менеджере файлов :-)

bash учить не нужно, к сожалению — его и так все знают, потому что без него жить не получается

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

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

Нет, я нашёл /etc/systemd/system, это же очевидно, что в Линуксе при желании найти глобальные конфиги нужно лезть в /etc и искать каталог/файл с названием программы.

Что касается юнитов пакетов, то авторы systemd сделали всё возможное, чтобы их нельзя было найти случайно, т.к. искать конфиги в каталоге /usr/lib линуксоиду в голову не придёт :-)

Ну, в одном из прошлых обсуждений кто-то из линуксоидов как раз жаловался, что юниты мало того что лежат в нестандартном месте, так еще и перезатираются пакетным менеджером :-)

bash — это жуткий монстр, который имеет кучу родовых травм и которому к сожалению нету нормальной замены.

Отсутствие нормальных массивов и хешей, поэтому во всех скриптах будте любезны эмулировать эти базовые вещи через переменные с подчеркиванием в виде разделителя. Потому что «должно работать везде» и на старых версиях тоже. В последней MacOS например до сих пор bash 3-й версии.
Ну и в придачу моя любимая нерешенная проблема с кавычками, которые просто теряются по дороге вызовов между функциями
$ cat script.sh
#!/bin/bash

echo "\$1="$1
echo "\$2="$2
echo "\$@="$@
$ ./script.sh "aaa bbb"
$1=aaa bbb
$2=
$@=aaa bbb
$ ./script.sh aaa bbb
$1=aaa
$2=bbb
$@=aaa bbb

$1 и $2 корректно отобразились, а вот $@ одинаковый в обеих случаях.

И таких приятных моментов в bash достаточно.

Никто не спорит, что баш — гадость. Речь шла о том, что простой скрипт для запуска сервиса написать может кто угодно, потому что всё равно ведь все работают в консоли, и чтобы написать скрипт не нужно знать ничего особенного сверх того, что и так уже используется в консоли — иными словами что отдельно и целенаправленно "учить баш" для этого не требуется.

Никто не спорит, что баш — гадость

Я спорю. Гадость, не гадость, однако попытки заменить его для интерактивной работы скажем питоном не получаются удобными.

А причём тут интерактив? Для интерактива есть zsh, fish, etc., но мы вроде скрипты обсуждали, а для скриптов реальных вариантов ровно два — bash или posix sh.

Скрипт простой только пока задачи простые, потом уже танцы с бубном, проверка возвратов функций, циклы retry и прочие извращения. Я тоже хотел бы как в *BSD, один скрипт и один конфиг где все настройки вида PROGRAM=YES|NO|PARAMS, и еще больше хотел бы как в OpenBSD где через ifconfig можно настроить абсолютно любую сеть (а не ifconfig, iwconfig, vconfig).

Но жизнь сложнее и поэтому простой скрипт инициализации сети (netifrc) в gentoo занимает 800+ строк, потому что проверяет кучу всего, и загружен ли модуль и разные форматы сетей понимает, но при этом большинство кошмара внутри это кака раз эмуляция массивов, и работа с ними.

Ну не согласен, я в консоли уже лет 20 наверное, и это все больно вспоминать, причем *BSD и линуксы были. Раньше тонны скриптов за собой тягал самописных для разных задач + настройки под все что можно консольное + настройки x-server. На сервере такая же жуть была, только там еще разные инит скрипты кастомные.

Тот же OpenRC почти всем устраивал, но перекрытия системных конфигов не было, поэтому вручную перекрывай и смотри чтобы не сломалось при обновлении. Инициализация сети — долго. А если сеть упала — то все можем после ребута не подняться из-за какого-то демона.

systemd — не панацея, те же страдания, только чуть меньше, поэтому и перешел на него. И потому что есть cron с человеческим лицом
Вообще-то зависит. Конкретный пример: чтобы чрутнуться без systemd, нужно ввести целый ряд команд, задействовав минимум 2 утилиты (mount, chroot), чтобы чрутнуться с systemd — достаточно 1 команды (systemd-nspawn)

Вообще-то с коллегой powerman я согласен. Не по форме, но по сути. Сколько я не рассуждал — про логирование, про мониторинг, про управление серверами (scm + оркестрация) — загадочным образом минимальное количество компонентов в минимальной работоспособной связке оказывалось величиной постоянной. Такие вот дела.

у меня Fluxbox и 24 виртуальных десктопа
Почему 24? Какие хоткеи назначены?

Вы вызываете у меня честно очень разные эмоции. Потому что "сборка дистрибутива под себя" — это правда очень круто. И очень здорово, когда человек может аргументированно пояснить, почему он взял такое решение, а не другое. С другой стороны, я вижу четкий крен у Вас в сторону докера (да нафиг он нужен на самом деле — меньше деталей — надежнее система, могу аргументировать). А если подумать еще, то вот это:


Ядро я собираю самостоятельно, и лишние драйвера и фичи в него не входят.

отличный способ пострелять себе по ногам. Ну, например, Вы выкинули все драйвера, кроме тех, которые есть на конкретной железке, где запущен Ваш линукс, а потом обновили железо. И чего-то не стартует — сеть, вайфай (самое критичное), потом все остальное, потому что чего-то не хватило.


Вот поэтому я и называю это юношеским максимализмом — это не дает никакого ощутимого бенефита, кроме возможно небольшой капельки опыта (это скорее в плюс) и личного ощущения прекрасного ;), зато времени жрет как не в себя с потенциально сомнительным на практике результатом. Я когда-то думал тоже, что удастся перехитрить индустрию или в чем-то превзойти кумиров. Оказалось, что нет — середнячок-с. Ресурсов нет.


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

Железо обновляется раз в несколько лет (с последним мне особо повезло — уже 8 лет на разогнанном i7-2600K, и только в этом году начал задумывать про апгрейд). И пересборка ядра в этом процессе отнимает самый минимум времени — гораздо больше уходит на то, чтобы сначала почитать обзоры и решить что брать, а потом собрать очередной тихий комп с громадными но тихими кулерами везде.


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

Притча про работу с ОЗУ как-то прошла мимо меня — Вы о чём конкретно?

Насчет ОЗУ пример https://habr.com/ru/company/oleg-bunin/blog/431536/
Это просто типичный пример "линукс дает памяти приложению столько, сколько оно запросит, без реальных гарантий наличия ОЗУ" -> все приложения начинают аллоцировать память как попало -> рано или поздно ОЗУ заканчивается и все заканчивается плачевно.
Я много игрался с overcommit и отсутствием свопа (кстати, последнее — официальный критерий работы кубернетеса). И могу сказать, что все плохо. Но возможно у меня попросту слишком завышенные ожидания от generic-purpose ядра и операционки.

Да, любопытно, спасибо. Я как-то не сталкивался раньше, или сталкивался но не проследил причину. Я много лет работал (на 16, потом на 24 GB RAM) без свопа, но в последнее время начал включать его на десктопах (с vm.swappiness = 1) — лучше когда машина начинает тормозить и по этому факту можно сориентироваться что браузер или телеграм как-то много гиг памяти скушали и пора их перезапустить, чем когда она просто умирает в этот момент. Но на серверах это не очень работает, там лучше о проблеме узнавать не по диким тормозам, а несколько ранее, по алертам от мониторинга. Так что смысл свопа на серверах от меня всё ещё ускользает.

Так что смысл свопа на серверах от меня всё ещё ускользает.

Мы с Вами динозавры. :-)

Один из аргументов адептов свопа заключается в том, что часть страниц памяти софта можно скинуть на диск без вреда для дальнейшей его работы. В этом есть определенная логика, т.к. любой софт сначала инициализируется, потом работает. И при переходе из первой во вторую стадию появляются данные, которые не нужны. И можно освободить ОЗУ тупо скинув эти страницы в своп. С другой стороны, есть куча доводов против свопа.

Звучит логично для активного используемого сервера. У нас вот сервер для внутренних ресурсов, и понятное дело ночью он стоит без дела. А ночью бекапы еще делаются. В итоге почти весь тот же гитлаб улетает в своп, а на утро все ждут, пока он проснется и вылезет из свопа. В итоге отключил нафиг и решаю проблемы по факту. Вижу OOMKill — добавляю виртуалке памяти.
А ночью бекапы еще делаются

бекапы еще можно снимать на уровне снапшота файловой системы или блочного устройства (там свои нюансы, но это может не аффектить саму операционку внутри виртуалки) — надо думать, как лучше сделать (баланс между просто/надежно/быстро/дешево/консистентный бекап).

Пока бэкап средствами самого гитлаба делается, так что тут без вариантов. А это естественно тонну файлов трогает, которые забивают весь файловый кэш. Тут то в своп все и сваливается, что давно не используется, а это как раз гитлаб сам, который под вечер простаивает.
Мы в похожем случае у одного клиента делали «прогрев» сайта и базы перед началом рабочего дня. Тупо wget'ом из крона несколько тяжелых страниц в /dev/null.
Так что смысл свопа на серверах от меня всё ещё ускользает.
Своп на серверах требуется просто потому, что выключить его полностью в Linux невозможно.

Да, его можно сделать нулевым и, типа, «отключить» — но это всё обман. Странички, загруженные из бинарников или mmapленные из файлов — можно выкинуть из памяти всегда, им выделенныей своп не нужен. А вот данные, которые просто размещены в памяти — без явно выделенного свопа сбросить на диск нельзя.

Это разделение данные на «данные первого сорта» (которые всегда доступны) и данные второго сорта (доступ к которым может быть сильно затруднён) — «кончается слезьми» очень много где… просто потому что код (без которого, как бы, сервер работать не может) — это как раз «данные второго сорта».

Забавно, но вот как раз в гитлабе бинарного кода мало (всего лишь интерпретатор ruby и библиотеки), а основная часть кода на файлы как раз не маппится. Оттого и эффект свопа выходит противоположным.

всего лишь интерпретатор ruby и библиотеки
И вот когда этот интерпретатор выгрузится и начнёт работать с тайкой скоростью, что ответ сервер удет давать не за миллисекунды, а за часы… вот тогда проблемы, собственно, и будут заметны.

Можно, конечно, прибивать такие сервера внешним watchdog'ом — кто ж спорит.

Можно OOM киллер прикрутить.

Но принципиально это проблему не решает.
Не знаю, какие там метаморфозы в ядре происходят, но полное удаление swap раздела делает свое дело. На серверах смысла я в нем тоже не вижу. Нет никакого контроля, что туда попадает, что приводит к непредсказуемому времени ответа серверных приложений. Про гитлаб выше я писал. Ждать, пока он из свопа вылезет, мне надоело. Поэтому нафиг его отключил и больше этой проблемы не знаю. Сервер отвечает всегда одинаково быстро. OOMKill для меня как раз полезное сообщение. Оно мне говорит, что надо памяти добавить, а не своп включить.

Что до пользы свопа и его неминуемости — все это я читал. Все эти советы одинаковые для всех ОС — своп неотъемлемая часть виртуальной памяти, всегда его включайте хотя бы небольшой и т.д. и т.п. Только практика показывает, что вреда от него на серверных ОС больше, чем пользы.
Что до пользы свопа и его неминуемости — все это я читал. Все эти советы одинаковые для всех ОС — своп неотъемлемая часть виртуальной памяти, всегда его включайте хотя бы небольшой и т.д. и т.п.

Ну, для Windows 98 это было актуально, для современных систем — нет, они прекрасно живут без свопа.


Все аргументы за включение свопа сводятся к одному и тому же: а вдруг у вас переполнится память? То есть 16 гигов памяти + 16 гигов свопа — ок, а 32 гига память без свопа — почему-то не ок.


Впрочем, отключение свопа действительно отключает некоторый функционал: hibernate, дампы в винды при крэше.

Причем тут винда, если речь про Линукс? Я уж не говорю про то, что оомкиллер (сюрприз! Сюрприз!) может срабатывать и при вполне свободной ОЗУ

Причем тут винда, если речь про Линукс?

Просто перечислил примеры случаев, когда нужен своп.
Так, в линуксе для hibernate своп нужен, в винде — нет (она сбрасывает память в отдельный файл). Зато в винде он нужен при блюскрине.


может срабатывать и при вполне свободной ОЗУ

Исчерпание виртуальной памяти при свободной физической вполне имеет место быть.

Тоже вариант. На самом деле для стабилизации системы можно даже вообще ничего не выгружать, а просто метитить некоторую часть страниц как «занятую» и не давать её под данные. Но давать под код. Чтобы успел сработать OOM-киллер.

Но это, всё, на самом деле — суррогаты свопа.

Исходная причина — что без свопа странички оказываются поделёнными на странички «первого сорта» и «второго сорта».

Ну вот я читаю про systemd — стоит ли с ним начать разбираться. Вроде часть моих проблем он решает, но в некоторых случаях проблемы создаёт. Например, не получается красиво подружить resolvd dnsmasq и Докер для локальной разработки.

Например, не получается красиво подружить resolvd dnsmasq и Докер для локальной разработки.

эта история в принципе красиво не решаема, в том числе и из-за особенностей доцкера. Т.е. это не проблема системди опять же

Пока в ubuntu был upstart, то нормально dnsmask работал с докер на моих задачах.

Ну, так отключите тогда systemd-resolved, если он мешает. В чем проблема?

Не взлетело простое systemctl disable systemd-resolved && apt install dnsmasq (по памяти) — совсем резолвинг отвалился. Ещё пробовал пару мануалов how to return dnsmasq in ubuntu 18.04 — вроде заработало, но с докером связать не получилось, он стал только на 8.8.8.8 фолбэк резолвить. Пару часов поковырялся и плюнул.

Мой коллега разработчик за вечер разобрался с аналогичной проблемой и предложил несколько решений в разных комбинациях демонов.
Т.е. проблема конечная и решаема.

Точно нет (не более опытный администратор, чем Вы — разве что более удачливый в каком-то смысле человек, но это тоже спорно)

Коллеги, которые минусали г-на VolCh — Вы бы вместо тихого молчания, попросту помогли коллеге разобраться с проблемой. Ну, ей-Богу. Человек, считай, старожил Хабра, адекватные вещи пишет, ну, не справился с резолвом — бывает.

systemd-resolve же висит на 127.0.0.53:53, нет?


~$  sudo  ss -tnlp | grep 53
LISTEN0 32 127.0.0.1:53 0.0.0.0:* users:(("dnsmasq",pid=31694,fd=11))                                            
LISTEN0 128 127.0.0.53%lo:53 0.0.0.0:* users:(("systemd-resolve",pid=31414,fd=13))

Докера нет, но использовать оба резольвера — никаких проблем. Более того, dnsmasq может использовать systemd-resolve как бэкенд.

systemctl disable systemd-resolved … — совсем резолвинг отвалился

Скорее всего, стало просто некому писать в /etc/resolv.conf, откуда приложения берут настройки dns. Сам пакет resolvconf в 18.04 не установлен. Но таки да, это проблема к systemd отношение если и имеет, то весьма опосредованное.

Один только реальный вопрос к вам — вы действительно сравниваете качество продукта по количеству задачек на гитхабе, учитывая что первый уже несколько лет используется во всех мажорных дистрибутивах?

Дальше риторический — а чего по звездочкам не сравнить, не очень выгодно получится?

Если бы речь шла о каком-то другом популярном и сложном продукте — да, конечно, больше популярность, больше фич ⇒ больше issues и багов. Проблема systemd в том, что мне в качестве PID 1 и загрузчика системы в принципе не нужен сложный и фичастый продукт — мне нужно что-то максимально простое и надёжное, потому что это слишком критичный элемент системы. А systemd простым и надёжным не является, отсюда тьма issues и багов.


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

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

Ваш же рассказ про Runit просто изобилирует таким проблемами: так не делать, вот это не использовать, сюда не нажимать… да, issues для них нету — ну так это скорее недостаток, а не преимущество.

У каждой системы и её автора есть свой взгляд на то, как ей надо пользоваться, а как не надо. И если ей пользоваться так, как задумано автором — обычно она работает лучше, и жить проще. systemd здесь ни разу не исключение, Поттеринг тоже крайне нетерпим к тем вариантам использования, с которыми он не согласен — напр. уже упоминавшийся здесь неоднократно journald.


Я лично согласен с тем подходом, который рекомендуется авторами runit и s6, и не согласен с тем, который рекомендуется systemd. Поэтому ограничения runit "сюда не нажимать" меня не беспокоят, я их воспринимаю не как ограничения моей свободы куда-то нажать, а как намёк, что есть более простой способ решения моей задачи — и обычно такой способ действительно есть.

Вот вам еще один пример из жизни systemd: systemd начинает отрабатывать/вычитывать системные настройки до того, как будут смонтированы все файловые системы описанные в fstab, и если вы делаете предположения, о том, что systemd сначала смонтирует все файловые системы, а затем начнет ими пользоваться, то вы рискуете попасть в неприятную ситуацию.

Ну а уж если вы решили использовать BIND, то незабудьте озаботиться написанием собственных генераторов [https://blog.iwakd.de/systemd-fstab-and-bind-mounts-with-options] -> blog.iwakd.de/sites/default/files/bindmount-generator.txt
в этом нет реальной необходимости: у меня Gentoo, причем даже

Ваш личный опыт не может быть мерилом глобальных явлений и потребностей.

появился Devuan, который «Debian без systemd». Википедия говорит, что есть 53 дистрибутива без systemd

Почти все они — далеко не в топе популярности, в этом суть.

1200+ issues, из них 89 открытых багов
Для сравнения, у OpenRC 61 issue, из них поиск по слову bug выдаёт 14

Демагогия с подменой понятий. Функциональность openrc — лишь небольшое подмножество функциональности systemd. И да, говорить «ну и зачем тогда нужно было делать жирный комбайн, если есть простой openrc/sysvinit?» — тоже демагогия. Потому что остальная функциональность systemd в случае openrc/sysvinit не пропадает, она так же существует в системе, просто реализуется другими программами, со своими багами и уязвимостями. Вся разница лишь в том, что все эти функции в systemd хорошо взаимоинтегрированы и легкодоступны пользователю благодаря унификации подходов и приёмов работы с ними, а в случае с openrc/sysvinit мы имеем ворох разнородных программ, смотанных изолентой.

Демагогия на демагогии и демагогией погоняет — вот и вся аргументация ненавистников systemd. А ещё ненавистники systemd очень любят говорить за всех, вещая что кому нужно и не нужно :-)
Почти все они — далеко не в топе популярности, в этом суть.
Миллионы мух не могут ошибаться, да.
Потому что остальная функциональность systemd в случае openrc/sysvinit не пропадает, она так же существует в системе, просто реализуется другими программами, со своими багами и уязвимостями.
У всех них есть фатальный недостаток же! Давайте кроме cron-а добавим Systemd Timer, чтобы сразу две программы выполняли одни и те же функции.
Давайте кроме cron-а добавим Systemd Timer, чтобы сразу две программы выполняли одни и те же функции.

Таймеры действительно очень мощный механизм, сильно лучше, чем крон. Фишка крона только в простоте и в том, что ему уже 30 лет в обед и все его проблемы известны. Но крон от этого лучше не становится. Жаль, что многи открывают таймеры для себя только сейчас

Давайте кроме cron-а добавим Systemd Timer, чтобы сразу две программы выполняли одни и те же функции.

«Всё сказанное может быть использовано против вас»


Админы localhost'а, скорее всего, с таким и не сталкивались никогда, но в реальной жизни сплошь и рядом проблема — многократный запуск кроном одного и того же процесса. Потому что во времена, когда «UNIX way ещё не был потерян» такой сценарий просто не встречался.


systemd.timer нам даёт «из коробки» гарантию, что не более 1 копии сервиса будет запущено, ограничение по времени работы, jitter времени запуска (чтобы 1000+ серверов не ломились разом обновлять список пакетов) и плюс, все остальные плюшки, которые systemd даёт. Даже можно сделать так, чтобы до/после сервиса запускался другой автоматически по зависимостям (с другими пермишнами, например).

многократный запуск кроном одного и того же процесса.

в результате — flock, lock и pid файлы и прочие костыли. Которые будут либо в строчке вызова в кроне, либо внутри самого запускаемого сервиса или скрипта. Нет, уж, спасибо — наелся


Как правильно заметили — в systemd такой фигни нет


А самая убер фишка (если мне память не изменяет) — вот предположим крон не отработал запуск скрипта по расписанию. Ну, или крон не был включен, или машина была в дауне. Никаких способов (внятных!) узнать, что скрипт не был запущен — не существует. И что хуже — если крон пропустил запуск, то он его пропустил и не будет при первой возможности скрипт запускать (а иногда это надо!!!). systemd решает эту проблему

Для решения этой проблема есть anacron.

Ну тут как раз и возникает ситуация — либо ты собираешь большую коллекцию разнообразных костылей и инструментов (причём для решения одной задачу у тебя будет пяток разных удобных программ, а для какой-то другой — только лишь набор костылей)… либо изучаешь один комплект программ — и с ним работаешь.
Админы localhost'а, скорее всего, с таким и не сталкивались никогда, но в реальной жизни сплошь и рядом проблема — многократный запуск кроном одного и того же процесса.
И чем эта проблема вызывается? Один и тот же скрипт дважды вносят?
ограничение по времени работы
А в чём здесь заслуга именно systemd? Если нужно ограничить время выполнения, то можно использовать timeout, если ограничить потребление процессора cpulimit и так далее.
Один и тот же скрипт дважды вносят?

Необязательно. Просто время выполнения старой копии пересеклось с запуском новой копии. Или не знаю — перевод на летнее/зимнее время Вы учли?
Повторюсь — в рамках крона и скриптописательства это все решаемо. Но это все выглядит как изобретение велосипеда заново каждый раз.


А в чём здесь заслуга именно systemd? Если нужно ограничить время выполнения, то можно использовать timeout, если ограничить потребление процессора cpulimit и так далее.

Стандартизация механизмов. Отрыв конфигурации (таймауты, лимиты...) от самого кода. Понятный менеджмент.

Стандартизация механизмов. Отрыв конфигурации (таймауты, лимиты...) от самого кода.
И в чём выгода вместо того, чтобы дописать что-то в строку запуска писать это как отдельный параметр? В одном случае есть скрипт на баше, в другом юнит файл. Количество строк в данном вопросе тоже отличаться особо не будет.
Выгода в том что когда вы заходите использовать ограничения для группы задач, то systemd позволяет делать это из коробки, в отличии от cron — который простой и тупой запускальщик задач и который про группы ничего не знает, так же как и ваши скрипты.

Ну и плюс дебаг задач cron это просто жесть.
А если не захочу? То этот оверхед будет просто болтаться в системе? А сколько людей кому это реально нужно?
Я предпочитаю чтобы у меня была возможность, чем потом при необходимости колхозить решение.

Если пугает оверхед то есть LFS, Gentoo и BSD.
Есть. Только вот для того чтобы была возможность у пары сотен человек, этот оверхед присутствует у сотен тысяч / миллионов.
И именно так — устроены современные платформы. Потому что гораздо проще и дешевле терпеть весь этот оверхед, чем разрабатывать десятки (сотни?) конфигураций всех программ.

Хотите сделал embedded что-нибудь, куда никакие «чужие» программы не ставятся — творите, что хотите.

А в массовой платформе — должны быть удотволерены потребности 99% пользоателей. Если даже в результате получится так, что каждый из них использует 1% возможностей платформы… но это будет разный 1% для каждого из них.
99% пользователей вообще пофигу, что там под капотом и systemd им просто не нужен.

systemd нужен софту, с которым работает пользователь. А пользователю действительно пофигу, главное, чтобы работало.

Заковыка в том, что зависимость пользовательского софта от systemd искуствено навязанная.
А давайте вы не будете решать за разработчиков чем им пользоваться, а чем не пользоваться?

systemd в современной GNU/Linux предоставляет набор функций, который никаким другим, кросс-дисстрибутивным, способом — не делаются.

А уж нужны эти функции программе или нет — это разработчику решать. Не вам, не мне и даже не «мейнетерам».
Почему нет? Некоторые из них решают же чем мне пользоваться, а чем нет. Спасибо мейнтейнерам Gentoo и Alpine, что они оставляют выбор за мной.
Например пресловутый Поттеринг втащил кодовую базу udev в кодовую базу systemd. Тем самым навязывая его. И только благодаря мейнтейнерам Gentoo я пользую eudev и не имею навязанного Поттерингом хлама в системе.

То есть если бы udev не шёл в комплекте с systemd, то вы бы пользовались systemd с удовольствием с eudev?

Если бы udev и всё остальное, не имеющее никакого отношения к PID 1, не шло в комплекте с systemd, им бы все пользовались с удовольствием.


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

А тем барахлом, что существует в реальности и называется systemd, добровольно пользуются только виндузятники, которым надёжность программ, а также удобство пользователей и разработчиков, дороже, чем принципы.
Ещё им пользуются те, кто уважают философию Unix и, в частности, такой важный пункт как «Пишите программы, которые бы работали вместе».

Напомню, что ни один Unix (настоящий Unix, ведущий родословную от разработки Кена Томпсона и Деннисом Ритчи) не позволяет вам выбирать, скажем, системный логгер.

Он там отдельный процесс да, но он является частью базовой системы и поставляется вместе с ней. Всегда.
Напомню, что ни один Unix (настоящий Unix, ведущий родословную от разработки Кена Томпсона и Деннисом Ритчи) не позволяет вам выбирать, скажем, системный логгер.

Отсюда, очевидно, следует, что в идеале cистемный логгер и должен быть частью системы и поставляться с ней. Всегда.


Вы хотите пользоваться философией Unix, а я хочу пользоваться собственно Unix. Ну или чем-то похожим на Unix. И у меня это было, у меня был GNU/Linux. А потом у меня забрали возможность пользоваться GNU/Linux и подсунули вместо него systemd.

Вы хотите пользоваться философией Unix, а я хочу пользоваться собственно Unix.
Что вас останавливает? FreeBSD и DragonFly BSD до сих пор существует.

Ну или чем-то похожим на Unix.
Проздравляю! systemd сделал GNU/Linux более похожим на настоящий Unix. Такой как Darwin (с его launchd) или Solaris (с SMF). Ваша мечта исполнена.

Отсюда, очевидно, следует, что в идеале cистемный логгер и должен быть частью системы и поставляться с ней. Всегда.
Не в идеале, а «в соотвествии с философией Unix». А идеал — он у всех разный. В этом-то вся и беда: нет никакого одного идеала, который бы устроил всех. А операционки, которые устраивают миллиарды пользователей, тем не менее, есть: Android, Windows, iOS (в этом порядке). systemd же — попытка сделать GNU/Linux ещё одной подобной…
А потом у меня забрали возможность пользоваться GNU/Linux
Какая конкретно часть GNU или Linux у вас пропала?

и подсунули вместо него systemd.
Systemd заменил как раз не компоненты GNU и не Linux, а ужасающую многоуровневую коллекцию костылей, подпёртых другими костылями, которая может нравиться, вы уж извините, только мазохистам.
Я бы пользовался udev как и раньше. До того как Поттеринг втащил его в systemd. Systemd в принципе для меня бесполезный bloatware.
До того как Поттеринг втащил его в systemd.
Ещё раз: Поттеринг ну никак не мог этого сделат. Куда-либо втащить udev могли только разработчики udev. А многие из них даже в RedHat не работают. И если они это сделали — то это был их выбор. А не ваш или Поттеринга.

Почему вы так яростно выступаете за вашу свободу и ваш выбор — но лишаете разрабочиков udev этой возможности?
Я за возможность выбора. Но я против поломки того, что работает. И против «починки» того, что не ломалось.
Например пресловутый Поттеринг втащил кодовую базу udev в кодовую базу systemd.
О как. Вот прямо так и втащил? А разработчики udev при этом сопротивлялись и плакали? Какой нехорошний Поттеринг, однако.

Я вам секрет скажу: без согласия разработчиков udev он бы ничего никуда втащить не смог.

И только благодаря мейнтейнерам Gentoo я пользую eudev и не имею навязанного Поттерингом хлама в системе.
До тех пор, пока вы это делаете молча и не рассказывая баек про то, как злой Поттеринг хлестал разработчиков udev розгами — это ваш выбор.

А вот когда вы начинаете стонать и плакать и требовать, что разработчики софта «входили в положение» и поддерживали Gentoo без systemd… вот тогда это перестаёт быть вашим личным делом, извините.
А вот тут не надо фантазировать. Я ничего ни у кого не требовал. Вы это сами придумали и приписали мне.
Миллионы мух не могут ошибаться

У всех них есть фатальный недостаток же! Давайте кроме cron-а добавим Systemd Timer, чтобы сразу две программы выполняли одни и те же функции

Правда, это тут считается нормальной аргументацией, а не детским кривлянием? Походу, Хабр реально заболел :-)

Позвольте поинтересоваться: зачем "кроме cron-а", когда можно (и нужно) "вместо cron-а"?

Это происходит в любом месте, где крон уже используется, а за настройку systemd никто не платит, либо лень менять уже работающие конфиги.
никто не платит

лень менять

Безусловно, это вина systemd и проклятого Поттеринга.
1200+ issues

это из-за распространенности (популярности) такое кол-во issues. На моих, никому не нужных проектах, 0 issues. Но это не значит, что их там нет)

начиналось как просто PID 1 и стала тем, что я бы назвал middleware современного дистрибутива Linux

И это плохо само по себе. Тем более, что опыт показывает, что в этом нет реальной необходимости: у меня Gentoo, причем даже не на OpenRC а на Runit, и при этом много лет используется udev (точнее eudev) и вот на днях перешёл на logind (точнее на elogind). Как видите, нет большой проблемы выделить полезные и нужные компоненты из systemd — или, говоря иначе, нет и небыло реальной технической (в отличие от политической!) необходимости изначально слеплять их в одно целое.

У меня на одном сервере пару сотен VLAN — так вот все кроме systemd боль и страдания. Все остальные системы инициализируют интерфейсы при загрузке и это занимает очень много времени (порядка 15 мин), с systemd все это за счет отложенной инициализации по необходимости занимает секунды.

Здесь реальная проблема не в том месте. У меня на десктопе под десяток VLAN-ов, каждый инициализируется ровно двумя строчками в /etc/runit/1 при загрузке системы и занимает это примерно нисколько, не смотря на синхронный запуск:


ip link add link enp9s0 name eth.wifi up type vlan id 6
ip addr add 192.168.6.1/24 dev eth.wifi
Все в одном скрипте — это как по мне возврат назад к истокам, с этого все начиналось и в 2020-м году этого уже недостаточно. Надо что-то сложнее чем две строчки — все страдай — пиши логику на баше. Надо айпишник получать по DHCP — страдай. Надо интерфейсы собрать в bonding — страдай. И это проблема именно тупого загрузчика — который просто выполняет скрипты загрузки. Такая же проблема с cron — тупым запускальщиком задач. И любой тупой инструмент — да супер надежный, потому что нечему ломаться, но если не устраивает то прийдется костылить и колхозить.

В целом, Вы правы, конечно. Только вот выводы из этого можно сделать разные — кто-то делает вывод, что нужен большой и сложный инструмент на все случаи жизни, а кто-то, что нужен ещё один мелкий и тупой инструмент конкретно под текущую задачу. Мне ближе последний подход. Но гораздо чаще случается кое-что другое: люди всё переусложняют на пустом месте, и пытаются решить проблему сложным способом не потому, что возможностей инструмента недостаточно, а просто потому, что не видят простое решение.


Надо что-то сложнее чем две строчки — все страдай — пиши логику на баше.

Вы не поверите, но обычно — не надо. Двух строчек хватает.


Надо айпишник получать по DHCP — страдай.

dhclient enp2s0 — одной строки хватает.


Надо интерфейсы собрать в bonding — страдай.

Этого я не делал, но вполне допускаю что тоже пары строку плюс по строке на интерфейс вполне может оказаться достаточно. Либо нужен отдельный простой инструмент, который умеет делать только это.


Такая же проблема с cron — тупым запускальщиком задач.

Не знаю, что конкретно Вы имели ввиду, но тут в обсуждении упоминалась ситуация, когда cron запускает дважды одну задачу из-за того, что она слишком долго работает, и это всё почему-то ломает. На мой взгляд, блокировка параллельного выполнения задачи, которую нельзя запускать параллельно — не задача cron, просто потому, что он далеко не единственный "запускальщик" в системе, и ту же задачу может запустить кто-то ещё (админ ручками, например). Задача должна блокировать себя самостоятельно, не перекладывая это на внешний инструмент — потому что внешний инструмент не может знать, какие задачи и на каких этапах их выполнения могут нуждаться в блокировках.

Количество багов это все-таки так себе метрика. У тех же компиляторов которыми не только все софт собирается, но и ядро багов многие тысячи и у gcc и у clang. Количество багов определяется также популярностью продукта.

… появился Devuan, который «Debian без systemd»
Это тот, который потратил два года, чтоюы перейти на Jessie и уже год, как не может версию на Buster выкатить? Оно вам точно надо?

Википедия говорит, что есть 53 дистрибутива без systemd.
И у скольки из них есть хотя бы 10 миллионов пользователей?

Я это к тому, что из Вашего описания складывается впечатление, что последние бастионы сопротивления пали на дебиане, и везде воцарился systemd… так вот, это не так.
С точки зрения обычного разработчика — это вполне себе так. Баги, вопроизводящиеся только на дистрибутивах без systemd уже вполне можно закрывать как WONTFIX.

Это, собственно, мне кажется главным достижением systemd. Остальное — мелочи.

А факты можно увидеть в базе CVE: 56 записей.
А давайте микрофактчекинг. Вот ткнул на одну их этих CVE (примерно посреди экрана): если сервис исполняется из под непривилигированного пользователя, локальный пользователь, имеющий права вышеописанного пользователя может перезаписать PID файл и убедить systemd убить какий-нибудь другой процесс.

Как и когда эта проблема была решена в вашем любимом Runit?

Про Runit сказать сложнее за отсутствием его на гитхабе, но насколько мне известно багов в нём нет.
Тем более интересно послушать как решается проблема с PID файлами.

В runit не используются pid-файлы, он контролирует запущенные процессы по SIGCHLD.