Re: ifupdown / systemd
On 2016-01-13, Sergey B Kirpichev wrote:
> On Wed, Jan 13, 2016 at 02:51:54PM +0200, Oleksandr Gavenko wrote:
>> On 2016-01-12, Sergey B Kirpichev wrote:
>> > Что вы предлагали в качестве решения проблем sysvinit?
>>
>> У sysvinit есть проблемы??
>
> Да, конечно. Я же уже приводил в качестве примера ужос
> с управлением сервисами /etc/init.d/foo start/stop.
>
Раньше считалось что init скрипт плохо написан если не прибивал детишек на
stop.
Давайте посмотрим на
http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
Linux Daemon Writing HOWTO, 2004
4. Basic Daemon Structure
Fork off the parent process
Change file mode mask (umask)
Open any logs for writing
Create a unique Session ID (SID)
Change the current working directory to a safe place
Close standard file descriptors
Enter actual daemon code
Парадигма сменилась - теперь systemd валит детишек через cgroup.
Т.е. отменяют шаг:
Create a unique Session ID (SID)
Спору нет - я за то что бы компьютер делал работу за меня.
Т.е. должны появиться новые требования к написанию демонов:
http://www.freedesktop.org/software/systemd/man/daemon.html
Ранее init-скритп знал как остановить демон, теперь появились требования:
If SIGTERM is received, shut down the daemon and exit cleanly.
If SIGHUP is received, reload the configuration files, if this applies.
Звучит отлично и мне нравятся эти соглашения!
Есть ощущение что монструозние сервисы, типа Oracle Database не перейдут на
systemd approach, вот как происходит старт/остановка:
$ sqlplus / as sysdba
SQL> STARTUP
SQL> SHUTDOWN IMMEDIATE
https://docs.oracle.com/cd/E17781_01/server.112/e18804/startup.htm
Кстати подскажите кто нибудь - активация через сокет:
If your daemon provides services to other local processes or remote clients
via a socket, it should be made socket-activatable following the scheme
pointed out below. Like D-Bus activation, this enables on-demand starting of
services as well as it allows improved parallelization of service start-up.
Also, for state-less protocols (such as syslog, DNS), a daemon implementing
socket-based activation can be restarted without losing a single request.
Это не то же самое что и inetd?
Или в systemd есть возможность прописать статическую и другие зависимости для
сервиса с сокет-активацией? Например не отвечать через сокет пока сервис
времени не обновил локальное время? Такие завичимости мне кажутся прогресом
(если они работают).
>> Года 2 назад systemd пропихивали с мантрой - паралельная загрузка, будем
>> грузиться быстрей.
>
> За этими обсуждениями я не следил достаточно, чтобы утверждать,
> что вы врете, но склонен полагать что это именно так. Как минимум,
Действительно, не совсем так. Про скорость хвастался Потеринг в 2013:
http://freedesktop.org/wiki/Software/systemd/Optimizations/
замечая что:
http://0pointer.de/blog/projects/the-biggest-myths.html
Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms,
anyone?), but that's primarily just a side-effect of doing things **right**.
Свежее интервью (2015):
https://www.linuxvoice.com/interview-lennart-poettering/
говорит интересные вещи:
* The Upstart way is always, “if this is started, then start that”. If the
network is up, you take that as a trigger to start NFS and things like
that. It always has this effect that you start as much as possible instead
of as little as possible.
...we came to the conclusion that Upstart is conceptually wrong...
Запускать что то только по необходимости - класно! Такое sysvinit не умеет.
Для этого inetd?
* So we started writing Systemd, and Red Hat didn’t like it at all. Red Hat
management said: no, we’re going for Upstart, don’t work on that. So I
said, OK, I’ll work on it in my free time. Eventually Red Hat realised that
the problems we solved with Systemd were relevant, and were problems that
needed to be solved, and that you couldn’t ignore them.
А тут забыл сказать что менеджеры увидели svhost.exe и возможность диктовать
условия рынку. Изветная стратения Mictosoft - вываливать раз в пятилетку новое
API, пока конкуренты адаптируют продукты они продают. Только RH дополнительно
к этому еще сможет продавать услуги по портированию и консалтинг ))
* Debian had its init scripts, and Fedora had its init scripts, and they all
kind of did the same thing, and did it differently, and some are better,
and some are worse. We thought OK: this is bullshit, let’s write this in C
in a unified way, and try to pick the best features of all distributions
and make a convincing argument that it’s the right way.
Классно!
Только снова ситуация как когда LSB описывал RPM и забыл про DEB ))
* Why do you think some distributions managed to adopt Systemd without any
major fights, and then others like Debian had very intense debates and
resignations?
Arch Linux probably did it the quickest way. You know, distributions
attract different kinds of people, of course. If you looked at Arch Linux,
it attracted very progressive kinds of people – like power users. They’re
progressive and want to make the best out of their computers. So it was
easy for them to adopt.
And Debian is probably an even more conservative bunch. Debian is a really
old project, and many people from back in the old days are still active on
it. So they have longer release cycles. ... So it’s to do with the culture
around the various distributions. And Slackware are the ultra
conservatives!
Итого стратегия Потеринга подождать пока вымрут старики. Старики - они такие,
не то что progressive kinds of people – like power users!
* LV: A lot of people just think there’s only Red Hat working on Systemd.
There are also developers from Debian – two or three of them.
Не они ли голосовали втихаря за Systemd ))
> в качестве причин для использования LSB-зависимостей - обычно
> приводят совсем другие. См. например wiki:
> https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
>
Неявное описание зависимостей через присвоение номеров - конешно тупизм.
Почему 20 (или быть может 40) лет была схема через нумерацию - не знаю.
Удобное соглашение + традиция наверно.
Схема не позволяла выяснить независимые сервисы. Мне кажется только потому и
сменили. Для других вещей в /etc/* никто не собирается переделывать
10-/20-/30-... т.к. важен только порядок, независимость не нужна для:
lighttpd/conf-enabled/...
common-lisp/source-registry.conf.d/...
fonts/conf.d/...
udev/rules.d/...
X11/xorg.conf.d/...
php5/cli/conf.d/...
BASIC программы 10 ... 20 ... 30 ... - что бы впоследствии можно было вставить
строчку посредине.
Т.е. можете столкнуться с ситуаций когда сделали маленькую дыроску для
расширения порядка выполнения - и тогда перенумеровывать геморно (ибо
вручную).
Явные (makefile-style) зависимости - это правильно. Они позволяют независимую
(т.е. паралельную) обработку.
Их достигли через LSB заголовки. Альтернативный синтаксис есть в systemd.
Правда теперь вместо сортированого списка файлов - нужна утилита для парсинга
и печати зависимостей.
--
http://defun.work/
Reply to: