К спорам по systemd и debian

Молодец, держи капитанские погоны.

ТС, а что ты ожидаешь кроме признания тебя КО или срачей?

haters gonna hate.

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

Для меня это тоже очевидные вещи, но не для Quazar, например

Ну мне например, он хорошо расставил все точки над i.

Никто не в курсе, когда планируется выкатить инсталлятор, сразу сетапящий дебиан с systemd?

Ну судя по всему на следующий стабильный релиз

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

Я имел в виду как финал внедрения

Но это же ЧИТАТЬ МАНЫ ОПЯТЬ МЫ РАЗУЧИЛИСЬ ЧИТАТЬ ДАЙТЕ НАМ ЖИТЬ С ИНИТСКРИПТАМИ ЗАЧЕМ МЕНЯТЬ.

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

systemd давно там есть

В следующем стейбле. Как он там? Джесси, вроде.

Я знаю, что системд есть в тестинговом репозитории. Вопрос в том, ставит ли текущий инсталлер тестинга системд, или ставит sysvinit, а системд потом руками прикручивается после установки?

1) Структура скриптов для sysvinit подразумевает только возможность запуска скриптов с флагами start и stop...

ТС путает rc(.d) и sysvinit. А может и не путает, но описывает так. Мда... Проповедник Поттеринга налицо.

И каким процессом запускаются скрипты из /etc/rc.d?

системд потом руками прикручивается

https://wiki.debian.org/ru/Systemd

openrc

Некая мифическая сущность, сферическая и в вакууме

хз, мне норм

раскажи, как ставил, в какой системе, чокаво, много ли скриптов из sysvinit юзается?

паралельной загрузки

1) не нужно
2) было реализовано задолго до

Некая мифическая сущность, сферическая и в вакууме.

не раскурил

упрощает внутреннюю логику юнитов

systemd вообще убивает какую-либо логику в скриптах, из-за чего и не нужен

не нужно

Старт какойнить самбы до старта самой сети это же так весело

systemd вообще убивает какую-либо логику в скриптах, из-за чего и не нужен

лол што? Системд не даёт писать логику там, где она ненужна, изза этого системд ненужен?

если тебя интересует именно rc.d, то /etc/rc
могу показать его содержание

если тебя интересует именно rc.d, то /etc/rc

khades@debian:~$ /etc/rc
-bash: /etc/rc: Нет такого файла или каталога

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

если тебя интересует именно rc.d

debian

хорошо вбросил, молодец. Особенно порадовала попытка запуска вместо cat. В палату мер и весов!

Старт какойнить самбы до старта самой сети это же так весело

нумерация скриптов? не, не встречал.

она ненужна

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

с каких пор несущим 4.2 среди прочего выдают капитанские погоны?

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

Пример юнита для nginx, где есть всё, о чём вы говорите.

[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/usr/sbin/nginx -s quit

[Install]
WantedBy=multi-user.target[\code]

я же у тебя спросил

И каким процессом запускаются скрипты из /etc/rc.d?

ты ответил что /etc/rc

где 4.2?

ну, и что неверно?

я запустил, и вы оказались не довольны

ога, вынести логику запуска/стопа в бинарь - это молодца. это пять с плюсом, настоящий Поттеринг-way

в init скрипте есть команда update, позвляющая обновлить бинарник nginx без закрытия соединений, покажите пожалуйска, как это выпонляется здесь. Можете ли вы показать, как при запуске сервиса будут обработаны случаи ошибок в конфиге (инит скрипт упадет при проверке со внятным логом и незапуском зависящих сервисов). Так же можно запустить конфигтест отдельно. Без этой логики инит имеет столько же строк:

description="Robust, small and high performance http and reverse proxy server"

nginx_config=${nginx_config:-/etc/nginx/nginx.conf}

command="/usr/sbin/nginx"
command_args="-c ${nginx_config}"
pidfile=${pidfile:-/run/nginx.pid}
user=${user:-nginx}
group=${group:-nginx}

depend() {
	need net
	use dns logger netmount
}

stop_post() {
	rm -f ${pidfile}
}

reload() {
	configtest || return 1
	ebegin "Refreshing nginx' configuration"
	kill -HUP `cat ${pidfile}` &>/dev/null
	eend $? "Failed to reload nginx"
}

подмена субъекта - это к специалисту. Это Я недоволен? Смехотворно!

1). статус openrc - полный ноль

2). зачем нужны cgroup, и приплетание их к PID 1

3). высказывание про selinux..

Ну а остальное.. я даже не знаю :)

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

системд скажет - Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.

В journalctl

-- Unit nginx.service has begun starting up.
фев 16 05:34:24 debian nginx[24213]: nginx: [emerg] unknown directive «12user» in /etc/nginx/nginx.conf:1
фев 16 05:34:24 debian nginx[24213]: nginx: configuration file /etc/nginx/nginx.conf test failed
фев 16 05:34:24 debian systemd[1]: nginx.service: control process exited, code=exited status=1
фев 16 05:34:24 debian systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has failed

сделай сервис foo зависящий от nginx и покажи процесс загрузки. Ну и ты проигнорировал более интересные вопросы.

kill -HUP `cat ${pidfile}` &>/dev/null

А потом выясняется, что nginx давно умер, а его PID занят другим процессом, который убивается по SIGHUP =).

встречаются такие экземпляры, что хочется просто плакать, когда их читаешь

А ты их не читай. Говнокод системдэ не читаешь, вот и их не читай.

rsyslog - программа для организации хранения этих сообщений, полученных по системной шине, реализованной в ядре linux (/dev/log)

journald - легковесный сервис для хранения и чтения логов с хранением их в памяти

Т.е. ради ускорения перезагрузки в среде латентных виндузятников решили пожертвовать надёжностью логгирования? Ну и задница.

на самом деле хз, почему не через s-s-d, который такую ситуацию отлавливает.

на самом деле хз, почему не через s-s-d, который такую ситуацию отлавливает.

Он эту ситуацию никак исправить не может.

1). статус openrc - полный ноль

[code]root@debian:/lib/systemd/system# apt-get install openrc
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Package openrc is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'openrc' has no installation candidate
[/code]

2). зачем нужны cgroup, и приплетание их к PID 1

3). высказывание про selinux..

Cgroup включет в себя изоляцию процессов: отдельный namespaces для групп, так, что одна группа не видит процессы, сетевые соединения и файлы другой (копипаста с wiki про идеальное состояние cgroup). Не правда ли напоминает selinux с его доменами? Про пид - просто указание механизма изоляции pid 1 от остальных процессов, а то читал такой бред, что сломанный процесс может негативно влиять на pid 1 вплость до уязвимостей и взлома

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

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

Должны ли они храниться в юнитах? Врядли. Во внешних конфигах? Возможно.

Не стоит всё подряд пихать в systemd и удивляться почему не влезает.

Представилась аналогия - впихивать в mvc-фреймворке во вьюху логику.

openrc - в тестинге на всех архитектурах, во всяком случае по сообщениям трех дебьянодевов находящихся на #openrc.

Cgroup включет в себя изоляцию процессов:

Какая к черту вики, мы тут из себя специалистов строим или кого? Требуется цитата из /usr/src/linux/Documentation или аналогичного по достоверности ресурса, можно и ссылку на исходники.

Namespaces и cgroups это совершенно не связанные между собой технологии.

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

Подожди. Он точно узнаёт, что на этом PID висит именно тот nginx или с него хватает соответствия имени?

сверхнизкую вероятность

man закон Мерфи.

race-condition

Даже не отрицаешь, что оно есть.

Кстати, кому принадлежит pid-файл и кто может в него писать? :)