Khades> Дописав ещё пару десяток строчек в каждый файл в /etc/init.d

Зачем?

Отладка SystemD.

HINT: Keep a copy of /sbin/init from sysvinit package in case of rescue (so you can use init=/sbin/init.sysvinit in cmdline)!

systemd вообще убивает какую-либо логику в скриптах

успокойся, бро! скоро впердолят JS и там хоть заскриптуйся

А это идея. Надо Леннарту предложить.

Забыли рассказать, что вся эта заварушка началась с жёсткой зависимости новых версий GNOME от systemd-logind.

фанаты леннарта не любят вспоминать столь малозначительные мелочи

уровень индиффириентности к гному по крайней мере у меня - 100%

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

Нет, потому что статус службы перейдет в crashed(скорее всего openrс хранит имя запущенного процесса в дополнение к PID, но тут не уверен). Поэтому даже если появится другой процесс с таким же PID, reload на него выполнить не удастся, только zap.

А я только сегодня удалил системде из своего дебианчика, хихик.

юниты systemd не скрипты, а конфиги. и положить в них какую-то логику принципиально не получится.

добавят секцию [JS]. какие проблеммы то?

тогда это будет уже не ini, а странный страшный гибрид. впрочем, Леннарт любит что-то такое говнистое.

юниты systemd не скрипты, а конфиги. и положить в них какую-то логику принципиально не получится.

Доо. Там вполне есть Exec*.

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

Вот проказник!

вроде в трэде уже говорили, что эти Exec - лишь ссылки на внешние файлы

Эти Exec*, когда я смотрел в последний раз, были местами, в которые можно вписать маленькие скрипты. Если это не «логика», то что же такое «логика»?

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

везде были ссылки на внешние файлы

И... это доказывает, что внешний файл не содержит логику?

можно пример обратного?

man systemd.service:

Example:

               ExecStart=/bin/sh -c 'dmesg | tac'

это доказывает

что systemd раздувает и усложняет инит.

/bin/sh -c 'dmesg | tac'

что является ссылкой на внешний бинарь

/bin/sh -c 'dmesg | tac'

что является ссылкой на внешний бинарь

Кхм. Вообще-то shell-выражение, использующее 3 внешних бинаря. И shell-выражение может быть любым.

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

я предпологал, что systemd-фаги странноваты, но не знал, что до такой степени.

это именно вызов бинаря sh c параметром

Ты правда не понимаешь, что такое shell-выражение? Окей.

я предпологал, что systemd-фаги странноваты, но не знал, что до такой степени.

Ты везде ошибся, бывает.

Вот пример сервиса с параметром

[Unit]
Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I
After=syslog.target network.target

[Service]
PrivateTmp=true
Type=forking
PIDFile=/var/run/openvpn/%i.pid
ExecStart=/usr/sbin/openvpn --daemon --writepid /var/run/openvpn/%i.pid --cd /etc/openvpn/ --config %i.conf

[Install]
WantedBy=multi-user.target

Например у меня есть в /etc/openvpn конфиг для рабочей сетки lidabeer.conf Я запускаю openvpn просто вот так: sudo systemctl start openvpn@lidabeer ну и на постоянку включил так sudo systemctl enable openvpn@lidabeer.

Как такое делается в других системах управления службами?

/Банальный раб Поттеринга

fixed

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

++

Да про баш ты прав. Да systemd крут и он должен убрать эту фрагментацию в линупсе. Но даже он не решает проблему запуска поганых java сервисов, которые в свою очередь работают через поганые баш скрипты.

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

Argument List Processing

-c Read commands from the command_string operand instead of from the standard input.

если инит на php, то

if ($argv[1]) {$StartUpCommand.="--config $argv[1].conf"}

/etc/init.d/openvpn start lidabeer

//shell не люблю и не знаю, код на нём привести не могу

я твои свежепридуманные базворды

Они мои не более, чем твои.

не понимаю и как-то не очень хочу понимать

Учись, студент. В жизни пригодится.

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

это твоё, свежепридуманное. выхлоп твоего бредогенератора

/me молча пожал плечами и добавил комментарий к нику.

А у меня даже udev'а нет!

В опенрц делается точно также, посмотри openvpn и net, причём задолго до системы, я помню как ещё над системдфанами можно было смеяться что этой функциональности нет.

А теперь интересный вопрос, как переопределить часть опций для конкретного %i, напр добавить лимиты?

Прямо никак. Или в конфиге самого соединения, или просто создав в /etc/systemd/system/ файл с полным названием и переопределив некоторые параметры.

Создание файла в /etc/systemd стандартная практика. Например, мне нужно было добавить в http несколько переменных окружения.

Так я просто создал файл такого содержания:

.include /lib/systemd/system/httpd.service
[Service]
Environment=TNS_ADMIN=/usr/lib/oracle/11.2/client64/lib

И всё. Может такое кому-то не удобно, по сравнению с прямым редактированием shell скрипта, но мне вполне хватает.

А в опенрц - как, или в конф файл пишешь настройка_и=«» или создаешь конф файл сервис.и.конф .

А в опенрц - как

Это разве плюс? Ну то есть весь смысл этого параметризованного юнита - вынести параметры из собственно логики запуска.

или создаешь конф файл сервис.и.конф

а для этого и в systemd есть EnvironmentFile или как его там

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

как environment-ом поставить ulimit, или cpu_limit?!

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

На самом деле ето deprecated (%

Сейчас параметры переопределяются заплатками drop-in, показывает сам systemctl:

user > systemctl status sshd   
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib64/systemd/system/sshd.service; enabled)
  Drop-In: /etc/systemd/system/sshd.service.d
           └─disable-tpm.conf
   Active: active (running) since Ср 2014-02-12 08:04:44 EET; 6 days ago
 Main PID: 2253 (sshd)
   CGroup: /system.slice/sshd.service
           └─2253 /usr/sbin/sshd -D -e

фев 12 08:04:44 WinterMute systemd[1]: Starting OpenSSH server daemon...
фев 12 08:04:44 WinterMute systemd[1]: Started OpenSSH server daemon.
фев 12 08:04:44 WinterMute sshd[2253]: Server listening on 0.0.0.0 port 22.
фев 12 08:04:44 WinterMute sshd[2253]: Server listening on :: port 22.
user > systemctl cat sshd   
# /usr/lib64/systemd/system/sshd.service
[Unit]
Description=OpenSSH server daemon
After=syslog.target network.target auditd.service

[Service]
ExecStartPre=/usr/bin/ssh-keygen -A
ExecStart=/usr/sbin/sshd -D -e
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/sshd.service.d/disable-tpm.conf
[Service]
Environment=TPM_ENABLED=disabled

user > 

Смотрите шырше. Все параметры переопределяются, я Environment для примера нарисовал.

1) Почему systemd должен упасть?

pulseaudio же падает.

2) Ядро тоже падает, давайте все ненавидеть ядро

Если есть одно слабое звено, то это не повод вводить ещё одно.

Ну вот, например:

user > srv daemon-reload                                                                               
user > srv start test@test.service                                                                     
user > cat /tmp/test.out                                                                               
10
user > srv start test@test2.service
user > cat /tmp/test.out           
unlimited
user > srv cat test@test2.service
# ~/.config/systemd/user/test@.service
[Unit]
Description=Just Test

[Service]
LimitCPU=10
ExecStart=/bin/sh -c 'ulimit -t >/tmp/test.out'

# ~/.config/systemd/user/test@test2.service.d/00-override-env.conf
[Service]
LimitCPU=infinity
user > 

мы

Перевод моей критики systemd на reddit'е

Предположим все дистрибутивы соберут systemd с флагами --disable-qrencode --disable-microhttpd и мне не надо будет говорить про влияние диссертации некего брата на ключевые компоненты системы. Посмотрим на реальные недостатки.

1. Всё прибито гвоздями. Это не моё мнение, это официальная позиция авторов: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabi... logind отдельно не переписать, journald «Maybe». Да даже «Unit file format» с какого-то перепугу объявлен приватным. Это - плохой дизайн.

2. Декларативный синтакс ini-файлов только скрывает сложность решаемой задачи. Надо будет решить что-то нестандартное и останется только стучаться в стену. Те кто писал на java с maven прекрасно знают о чём я говорю. java программисты закопали maven, теперь линуксоиды радостно бросились в ту же пропасть.

3. Бинарные логи. Да ещё с внутренней организацией что б разные части лога были за-mmap'лены по-разному. Конец у нас transaction log, поэтому append-only, а середина индексы, поэтому изменяема. До нас эту задачу не решал никто, надо свой новый формат придумывать, конечно. Документированные на уровне C-структур только, нда...

4. API никто не дизайнил вообще, самро выросло из реализации кое-как. Например mount и automount это у нас разные типы юнитов, зато все сервисы свалены в один тип юнитов «service», а чтобы их отличать введён аттрибут «Type» («oneshot», «forking»). Если бы систему кто-то проектировал, то либо был бы один тип юнита mount с под-типами «auto» и «manual», либо сервисы были бы раскиданными по разным типам юнитов. А так в одном месте одно решение, в другом другое, в результате - каша.

5. Качество кода. Я взял дефолтное действие основной пользовательской утилиты systemctl и проследил за её исполнением. По ходу встретил неоткомментированную функцию сортировки юнитов (в недокумментированном порядке) и одну замечательную проверку, которая позволяет иметь в системе скрытые от админа сервисы (привет руткитам!). Тоже, естественно, без комментариев: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c#n708

Некий девелопер наговорил кучу красивых слов как всё правильно надо сделать и всех убедил. Идеи и правда хорошие. Но вот код он писать НЕ УМЕЕТ. И проектировать ПО тоже. Пусть будет гуру, идеологом, кем угодно. Но вот код, который он пишет, нужно за ним весь переписывать как положено. А не включать в ведущие репозитории по-умолчанию.