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/
