Какой системой инициализации должен комплектоваться Debian Stable по умолчанию?

SystemD, ибо с ним удобнее всего админить серверы.

ты слишком неуважительно относишься к специалистам

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

реквестую закрытие этого голосования и создание нового

Да маны то я покурю. Я другое понять не могу, нафига гуй демонизировать, это же - уязвимость.

нафига гуй демонизировать

??

это же - уязвимость

???

Распишешь, как проводилась диагностика и в чём оказалась проблема

Хорошо. Мы (смешанная комиссия: 2 сисадмина и веб-программист) тогда принимали решение о переходе с openSuSe 11.4 на 12.1 (точно не помню, так что может и 12.2). На 12.1 нужно было протестировать работу самописного веб-приложения под большой нагрузкой. Нагрузку обеспечивали три отдельные машины, на каждой из которых был запущен многозадачный скрипт эмулирующий запросы к приложению. Машины были тюнингованы (изменен ряд параметров в sysctl) для достижения максимального результата. Количество воркеров я уже не помню, но помню что их количество было пропорционально количеству ядер - то ли по два на ядро, то ли по четыре на ядро.

И были две машины с веб-приложением, реверс-проксирование на которых осуществлял nginx. На одной была OpenSuSE 11.4, а на другой 12.1 с systemd. Обе машины отлично справились с нагрузкой и даже почти не лагали. Затык возник при тестировании, на обновление конфигурации реверс-прокси nginx.

По условиям теста, мы должны были добавить директиву в конфиг, выполнить проверку командой nginx -t и затем рестартовать сервис. Без нагрузки все прокатывало на ура, но под нагрузкой systemd из 10 ппыток ронял nginx и не мог его поднять дважды.

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

Ты не специалист, ты та грязь, что позорит самим своим существованием принцип сертификации специалистов

Ты хоть через раз закусывай что ли? А то вот не знаю, что там позорю я, но ты администрацию ЛОРа точно выставляешь с самом неприглядном свете.

Я к администрации ЛОРа имею отношения не больше, чем ты.
Ты себя показал как человек, неспособный к обучению, махающий сертификатами и просто фанатик :)

Я к администрации ЛОРа имею отношения не больше, чем ты.
Статус: ★★★★★ (корректор)

«Поздравляю вас, господин соврамший!» (с) Мастер и Маргарита

Ты себя показал как человек, неспособный к обучению

Ага, это видимо потому что я не из Потериговых разРабов?

махающий сертификатами

Ну, у меня они по-крайней мере есть. Но о тебе-то этого не скажешь, верно?

просто фанатик :)

Да, уймись уже, балаболка... достал ты меня.

Systemd чтобы не разводить зоопарк

Всем доброго времени суток.
Я пользуюсь Ubuntu, следовательно у меня Upstart(если я всё правильно понимаю). К чему все эти холивары на тему инициализации, если всё работает? Или я счастливчик и у остальных всё валится? Кто ни будь может без околорелигиозных истерик объяснить?
Заранее спасибо.
P.S. Есть подозрение что всё дело в том. что у меня не сервер, хотя вроде истерят не только сисадмины.

«Поздравляю вас, господин соврамший!» (с) Мастер и Маргарита

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

Ага, это видимо потому что я не из Потериговых разРабов?

Это потому, что ты не смог разобраться с инструментом, и на этом основании объявил его плохим. Nuff said.

Ну, у меня они по-крайней мере есть. Но о тебе-то этого не скажешь, верно?

Повесь в сортире. У меня есть другие, уровнем несколько повыше и к админству и IT вообще отношения не имеющие. Как говорится, «у меня длиннее», утрись, неудачник.

Да, уймись уже, балаболка... достал ты меня.

Это интернет, детка. Тут и послать могут. (с)

Техсовет разве читает этот тред?

а вдруг?

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

Я считаю, что Upstart оптимален: широкие возможности, и при этом не подминает всю систему под себя. Если бы речь не шла о Дебиане, который по определению должен быть консервативен, и ни в коем случае не полагаться, на систему, которой нет ещё и десяти лет.

Вообще-то, я не спрашивал, что вы делали, я спрашивал в чём была проблема

Как мы поняли, проблема была в удалении pid'а из /run Во всяком случае, он там был, а процесса в памяти - нет

Из описания непонятно, одна и та же или разная версия nginx, самосборная или из репозиториев

Если специально не оговорено, то предполагается, что версия из стандартного репозитория.

пытались ли вы написать нативный .service файл

Нет, не пытались.

Вот да, upstart - наилучшее решение (хотя сослепу проголосовал за systemd, лол :))

Systemd, конечно, становится «почти мейнстримом», но это такой мейнстрим, что лучше бы его вообще не было... Такая вот, блин, норма, если поняли, о чем я...

Вот например, как мне под systemd нормально выставить параметры в /sys, если tmpfiles.d исполняется раньше загрузки всех нужных модулей? Ну и прочие мелкие радости вроде socket сервисов :) которые в принципе как идея неплохи, но вот реализация...

Где вариант «Мне плевать, какая система инициализации будет в Дебьяне»?

Можно еще несколько вариантов добавить:

XXX (...и при этом я использую Debian. мне пофиг!)

Не нужно быть таким безучастным :)

Как мы поняли, проблема была в удалении pid'а из /run Во всяком случае, он там был, а процесса в памяти - нет

Ну и каким боком тут systemd? Для init.d/ скриптов он стартом/стопом и пидами не занимается. Раз pid остался, значит при /etc/init.d/nginx restart что-то пошло не так.

Upstart

Ну и каким боком тут systemd? Для init.d/ скриптов он стартом/стопом и пидами не занимается. Раз pid остался, значит при /etc/init.d/nginx restart что-то пошло не так.

Да, ладно тебе: не было никакого там init.d-скрипта. В этой версии сузи их уже как бы нет «ис коропки». И pid не был генерен nginx'ом, ибо явно отключена была эта опция. А вот смена рута (первоначального владельца процесса) на пользователя nginx как раз имела место быть. А pid который в run'е сидел, он был рутовый. Так что мы сделали вывод, что милейший systemd запутался в трех соснах двух пользователях и не смог в контексте одного, удалить pid другого. А вот каким боком здесь нагрузка, скажу честно - ХЗ.

А OpenRC , как вариант они разве рассматривают?

Я вот думаю принятия OpenRC не будет какой-то катастрофой. Если даже sysvinit до сих пор годный, то что-то более современное типа OpenRC и то - хорошо.

И вот еще, что: ты пойми. мы бы отладили башевые скрипты без проблем (во всяком случае были прецеденты, когда приперало), ибо мы все, и веб-программисты и сисадмины, его знаем. А системд - тут ведь сишник нужен, и причем не новичок. Так вот и получилось, что сменить круто-новомодно-обновленную сусю на генту с OpenRC стало просто целесообразнее. На OpenRC, мы сделали небольшую рихтовку (пару раз всего пришлось руки приложить), а во всем остальном работает она, ну как часы. А системд? Ну пусть его на десктопах юзают вчерашние хомячки.

А системд - тут ведь сишник нужен, и причем не новичок

Что, простите? Демьяновский nginx.service:

cat nginx.service
[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

не было никакого там init.d-скрипта

Тогда это была не опенсуся 12.х. 12.1, 12.2 — только init-скрипт, 12.3 — init-скрипт и .service

не надо портить дебиан. убрали бы ещё пульс аудио к бабушке.

И pid не был генерен nginx'ом, ибо явно отключена была эта опция

pid генерится /sbin/startproc

Ну и что тебе даст лицезрение спецификации сервиса, стесняюсь спросить?! Пойми, без отладки такие проблемы с какими мы столкнулись не решаются. Если ты возмешься системд отлаживать, то ты - герой-сишник. А вот я не возьмусь. Это в отличие от OpenRC, которую любой из нашей конторы (кроме разве что буха) отрихтует. Так что и выбор у меня очень простой: сменить systemd на OpenRC или нанять сишника, который стоит не меньше сорока рублей в месяц. А оно мне надо ему платить? Я что, по другому эти сорок рублей не потрачу?

Ну и что тебе даст лицезрение спецификации сервиса, стесняюсь спросить?!

Ровно столько же, сколько даёт лицезрение bash-скрипта.

pid генерится /sbin/startproc

Некоторые демоны (и nginx в их числе) сами могут генерить pid. У nginx, частности за это отвечает ключ -g

А вот я не возьмусь.

не осилил С? прими соболезнования.

Это в отличие от OpenRC, которую любой из нашей конторы (кроме разве что буха) отрихтует.

бугагашеньки, какую же херню ты несешь.

не осилил С? прими соболезнования.

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

Уметь они могу всё, что угодно. Конкретно в opensuse 12.1 и 12.2 nginx стартует только так и никак иначе:

case "$1" in
    start)
        echo -n "Starting nginx "
        ## Start daemon with startproc(8). If this fails
        ## the return value is set appropriately by startproc.
        /sbin/startproc -p $NGINX_PID $NGINX_BIN

        # Remember status and be verbose
        rc_status -v
        ;;
    stop)
        echo -n "Shutting down nginx "
        ## Stop daemon with killproc(8) and if this fails
        ## killproc sets the return value according to LSB.

        /sbin/killproc -p $NGINX_PID -TERM $NGINX_BIN

        # Remember status and be verbose
        rc_status -v
        ;;
<cut>
    restart)
        ## Stop the service and regardless of whether it was
        ## running or not, start it again.
        $0 stop
        $0 start

        # Remember status and be quiet
        rc_status
        ;;

Послушай, я же уже говорил, что точно версию сусе с системд по обязалову не помню. Но именно это обязалово и заставило нас тратить время на тесты, потому как все понимали, что если обвалится продакш, то будет попа ЖОПА. Так что никаких init-скриптов в духе старой-доброй слаки там уже и близко не было к тому времени. И рестартовали мы службы командой systemctl

А то, что ты привел - это как раз было в 11.4, и это-то как раз работало без проблем.

smss.exe

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

И рестартовали мы службы командой systemctl

Это говорит ни о чём. В отсутствие нативного сервиса systemctl может работать и со скриптами sysv.

systemctl status wine.service
wine.service - LSB: Allow users to run Windows(tm) applications
   Loaded: loaded (/etc/rc.d/init.d/wine)
   Active: active (exited) since Пт. 2014-01-31 16:26:42 YEKT; 1 weeks 1 days ago

то смотрели ли вы логи системд и нгинкса с уровнем debug?

Сперва нет, поскольку на продакшене (а это был тест продакшена) все отладочные сообщения отключаются, за исключением уровня critical. Потом включили логи доступа nginx (отладку уровня DEBUG без пересборки в nginx включить нельзя, и она по-умолчанию отключена) - замечаний в них не было. В журнале системд была ошибка доступа к файлу pid'а (acess denied). Без подробностей.

Пробовали ли systemctl reload вместо systemctl restart?

Да, результат был такой же - «плавающая» ошибка, с вероятностью примерно 2/10

Пробовали ли посылать сигналы nginx'у напрямую?

Да. kill hup нормально рестартовал сервис, как ему и полагается, без малейших замечаний, а kill term так же без замечаний убивал процесс.

Systemd чтобы не разводить зоопарк

ein извилина, ein поцтеринг, ein сисямдэ? NO WAY!

SystemD

http://freedesktop.org/wiki/Software/systemd/#spelling ну

openrc ибо чем дальше тем оно прямее

init - самый первый процесс, стартующий в системе, его pid всегда 1. init находится в корне дерева всех процессов.
демоны - процессы с pid<100, они выполняются с большим приоритетом чем все остальные процессы.

Тред не читал, но вот это просто безапелляционное 4.2.

Вообще, это смесь неканоничного написания («S») и мимикрии под исходное голосование в tech-ctte Debian (там были буквенные сокращения вида D = systemD, U = Upstart, V = sysVinit, O = Openrc).

SystemD

Оставить SysV.

Либо OpenRC либо Upstart. Голосовал за Upstart, но сейчас думаю что и OpenRC тоже хорошо.

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

Ах, так вот какая задача ставится - вообще отказаться от скриптов инициализации. Но это уже совершенно другая операционная система будет. А как init без скрипта будет перезапускать демон, если тот упадёт?