Регистрация | Войти
Lisp — программируемый язык программирования
RSS
Проект "daemonization"
LinkFly - 22.01.2011 09:32, Сообщений - 17
    Приветствую всех форумчан. В связи с замеченным проявлением интереса к этой теме (к теме демонизации), хочу представить свой проект, предназначенный для демонизации лисп-процессов. Сразу оговорюсь - проект не готов, не отлажен и прочее. Но при этом готов концептуально.
Проект притендует на многое и поэтому является весьма спорным. Интересно то, что если бы мне рассказали бы о целях проекта (до того как у меня созрела идея его реализовать) - моё отношение
к этому было бы в высшей степени скептическое вплоть до полного его игнорирования. Однако,
в процессе созревания концепции проекта я понял что, при хорошем и лаконичем дизайне проекта,
адекватном поставленным целям я мог бы создать некоторую рабочую базу для постепенного доведение проекта до полного завершения (надеюсь не только собственными силами). Проект мне представляется не супер-полезным и супер-нужным, но всё же полезным и нужным. Кроме того, один из стимулов его реализации, это попытка ответа на вопрос: "Что есть хорошая архитектура проекта в кроссплатформенном системном программировании на Common Lisp". Звучит правда, несколько пародоксально :) 

Вот несколько строк из README проекта:

Система предназначена для инкапсуляции всего функционала связаного с "демонизацией" лисп-процесса без
использование screen/detachtty, нацелена на работу на как можно большем кол-ве lisp-систем
и операционных систем. Во многом базируется на коде из restas-daemon.lisp
(копирайт Москвитин Андрей <archimag@gmail.com> распространяется под лицензией LGPL.)

[1] https://github.com/archimag/restas/blob/master/contrib/restas-daemon.lisp

-----------------
Описание файлов:


А вот собственно ссылки на README (который будет изменяться) и на сам проект:

https://github.com/LinkFly/daemonization/blob/master/README

https://github.com/LinkFly/daemonization
[#]
Ключевой вопрос - какая есть потребность в данном проекте? 

Просто, лично я не могу работать над тем, что мне не нужно. В плане демонизации мне нужно ровно то, что у меня сейчас есть. Я изначально хотел сделать более универсальную схему, но потом заметил множество проблем, в преодолении которых я совершенно лично не заинтересован. Поэтому решил делать более просто.

ИМХО, проект в описанном виде, вряд ли будет интересен большому количеству разработчиков. 
archimag - 24.01.2011 03:45
[#] Ответ на комментарий от archimag 24.01.2011 03:45
Лично у меня потребность в следующем:
Полностью отделить демонизацию в restas-daemon.lisp от restas-специфичных вещей (и вообще от более высокоуровнего кода). Нужно это вследствии того,что мне необходимо расширять restas-daemon.lisp, а делать это работая с одним файлов не удобно (тем более содержащем множество низкоуровневого системного кода). Расширения предполагаются (кое-что уже используется в моей версии restas-daemon.lisp) как связанные с restas, с другим высокоуровневым кодом, так и связанные с демонизацией. Кроме того, мне нужна "закладка" - после того как будет полностью доделана работа системы на linux/sbcl, я хочу иметь возможность (при необходимости) быстрой и удобной доводки  до работы на другой лисп-системе как минимум и другой ОС как максимум. Далее планируется сделать restas-daemon-ext (файл или ASDF-систему - по ситуации), который будет использовать daemonization и сам будет использоваться вышележащей системой/модулем.

> ИМХО, проект в описанном виде, вряд ли будет интересен большому количеству разработчиков.

Очевидно в незавершенном виде только разве что писавшим/переписывающим/изучавшим restas-daemon.lisp и интересующимся системным программированием в CL/sbcl.
LinkFly - 24.01.2011 07:34
[#] Ответ на комментарий от LinkFly 24.01.2011 07:34
> и сам будет использоваться вышележащей системой/модулем.

Круто сказано ) На самом деле будет просто несколько shell-скриптов :)
LinkFly - 24.01.2011 07:36
[#] Ответ на комментарий от LinkFly 24.01.2011 07:34
> и сам будет использоваться вышележащей системой/модулем.

Круто сказано ) На самом деле будет просто несколько shell-скриптов :)
LinkFly - 24.01.2011 07:36
[#] Ответ на комментарий от LinkFly 24.01.2011 07:34
> Нужно это вследствии того,что мне необходимо расширять restas-daemon.lisp, 

Хм, зачем? Может проблему можно решить без изменения демона?
archimag - 24.01.2011 07:43
[#] Ответ на комментарий от archimag 24.01.2011 07:43
Да собственно по настоящий момент так и делается. И речь идет не конкретной одной проблеме, а о множестве появляющихся задач. Так или иначе, а идея инкапсуляции всего связанного с демонизацией (и закладка для расширения для других лиспов/осей) - представляется достаточно "вкусной".
LinkFly - 24.01.2011 08:15
[#] Ответ на комментарий от LinkFly 24.01.2011 08:15
> И речь идет не конкретной одной проблеме, а о множестве появляющихся задач.

Слишком абстрактно. Можно пример?

> идея инкапсуляции всего связанного с демонизацией ... - представляется достаточно "вкусной".

Она была бы "вкусной", если бы мы имели множество серверов, работающих под разными системами, и имели бы проблемы в обслуживании из-за необходимости постоянного учёта особенностей систем. Я не знаю кто может похвастаться тем, что имеет подобную ситуацию )
archimag - 24.01.2011 08:40
[#] Ответ на комментарий от archimag 24.01.2011 08:40
Например: я как-то добавил новый параметр - путь по которому располагаются либы. Причём нужно было чтобы не было требований к иерархии систем, то есть чтобы они располагались произвольным образом и чтобы не нужно было при любом изменении дерева каталогов править какие-то конфиги (это как раз то, что было добавлено в ASDF2). Причем по некоторым причинам удобно было задавать путь именно в общем конфиге. В определённой ситуации (при использовании демона) случался глюк: проход по директориям зависал. Было исправлено переносом соотв. кода в другое место в файле. Глюк был связан с какими то низкоуровневыми нюансами, разбираться с которыми было совершенно не кстати. В итоге для решения достаточно высокоуровневой задачи пришлось работать с низкоуровневым кодом. Что было совершенно не удобно. Может быть не самый лучший пример, но имеет место (были ещё преценденты). И нужны ещё расширения, а с ростом объёма файла сложность редактирования и вероятность "сюрпризов" возрастает.
Да и вообще инкапсуляция такого понятия как демонизация в отдельную систему кажется совершенно очевидной и удобной. Согласен что с целью "работа на всех лиспах и ОСях" можно спорить. Однако при хорошем разделении на слои (что уже сделано) в этом (ИМХО) есть смысл.

> Она была бы "вкусной", если бы мы имели множество серверов, работающих под разными системами, и имели бы проблемы в обслуживании из-за необходимости постоянного учёта особенностей систем. Я не знаю кто может похвастаться тем, что имеет подобную ситуацию )

Мне не хотелось бы чтобы запуск лисп-системы как демона был намертво привязан к ОСи и лисп-системе. Логично для библиотеки предназначенной для общего пользования стремится к работе в разных условиях. И не хотелось бы при любой смене конфигурации "разводить руками" и тратить время на написание своего restas-daemon. Понятно что всего не предусмотришь, но иметь некоторую основу, которую можно относительно быстро "про- апгрейдить" до работы в нужных условиях - хотелось бы. Степень готовности такая, что довести до полноценной работы на linux/sbcl не очень трудоёмко. А если появятся пользователи у которых будет необходимость работы на другой конфигурации и они добавят соотв. код - то это же вообще шоколадно.

Как я уже отмечал выше: библиотека не сверхполезная, но полезная, мне по крайней мере нужна. Да, и видимо не только мне одному:
http://www.cliki.net/Vladimir%20Sedach
His Common Lisp projects-that-would-be-cool list:
...
Portable cross-platform server daemonization library ala RESTAS-daemon (because screen/detachtty isn't always a good thing)
LinkFly - 24.01.2011 11:18
[#] Ответ на комментарий от LinkFly 24.01.2011 11:18
Лично я хочу даемонизацию что бы использовать daemontools supervise или runit на Линуксе с SBCL, CCL, и CLISP. Я пробовал наладить supervise со screenом но ни как не смог их совместить. Было бы приятно если будет поддержка FreeBSD. А дальше добавить OpenBSD, OpenSolaris и тд тогда будет не трудно. Думаю нет смысла разрабатывать это для винды и OS X тк там все по другому и уже есть коммерческие разработки от Franz и LispWorks.
vsedach - 31.01.2011 18:28
[#] Ответ на комментарий от vsedach 31.01.2011 18:28
Интересно было бы узнать про какие-нибудь "подводные камни" на которые можно наткнуться при демонизации процесса на разных системах (на разных *nix системах). Я конечно, отдаю себе отчёт в том, что подводные камни появятся при непосредственном контакте с системами :)
Но всё-таки, если какие-то станут известны уже сейчас, то это будет очень полезно, ибо подкорректировать архитектуру системы пока ещё достаточно просто.
LinkFly - 17.03.2011 14:22
[#]
> без использование screen/detachtty

А мне вот в своей запускалке hunchentoot-а пришлось писать на си, т.к. у чисто-лиспового решения есть очевидный недостаток - если лисп-процесс умрёт, то его некому будет перезапустить (если делать лисповый демонизатор отдельным процессом - будет слишком жирно). Т.е. демонизация, это, вообще, частный случай рестартера.

treep - 17.03.2011 16:59
[#] Ответ на комментарий от treep 17.03.2011 16:59
.. ну я бы не сказал что демонизация частный случай рестартера.
Как бы там ни было, рестартер это всё таки отдельная тема. Хотя можно совместить.
Можно например, добавить ключевой параметр, через который можно при желании передавать
ф-ию, которая запуститься с pid дочернего процесса вместо в процессе родительском вместо простого
выхода  (и это может быть в частности рестартер).
Если жаба душит, держать ещё один лисп процесс, то передаваемая ф-ия может запускать какой-то внешний
рестартер. Но в любом случае он должен быть отдельно.
LinkFly - 17.03.2011 18:00
[#] Ответ на комментарий от treep 17.03.2011 16:59
> если лисп-процесс умрёт, то его некому будет перезапустить

Лисп здесь не при чём, надо смотреть в сторону daemontools.
archimag - 17.03.2011 18:12
[#] Ответ на комментарий от LinkFly 17.03.2011 18:00
> .. ну я бы не сказал что демонизация частный случай рестартера. 

Обычно рестартуют сервисы в винде и демоны в юниксах, т.е. если что-то рестартуется, то его сначало нужно сделать демоном. И обычно процесс рестарта тесно связан с процесом демонизации: сначала происходит демонизация и fork, получившийся процесс становится рестартером-демоном, предок завершается, потом рестартер-демон алоцирует массив/связный список и осуществляет ряд демонизаций fork-ов - получаются ревизируемые демоны которые время от времени проверяет на состояние рестартер. Т.е. получается, что если просто демонизировать, то можно сделать pure-lisp решение, а если ещё и перезапускать - то уже нужно либо всё на си писать, либо pure-lisp демонизатор + рестартор на си, или отжалеть ~100MB на sbcl-рестартор :)
treep - 18.03.2011 00:53
[#] Ответ на комментарий от archimag 17.03.2011 18:12
> Лисп здесь не при чём, надо смотреть в сторону daemontools.

А кстати, чем screen конкретно плох? Он же тоже из этой оперы (daemontools).
treep - 18.03.2011 00:54
[#]
Вот, кстати, как в Erlang сделано - http://www.erlang.org/doc/man/erl.html, т.е. есть ключ detached у самой VM (на уровне си кода, видимо). В этом смысле удобнее было бы наличие ключей --daemon (для открепления от стандартных дескрипторов), --restart (супервизор), и --lock (для блокирования вторых версий) у SBCL.
treep - 18.03.2011 05:48
[#] Ответ на комментарий от treep 18.03.2011 05:48
> то уже нужно либо всё на си писать, либо pure-lisp демонизатор + рестартор на си, или отжалеть ~100MB на sbcl-рестартор :)

Нее, на Си "всё" точно не надо писать. А насчёт ~100MB: во-первых это по ситуации, если требуется какой-то крошечный встраиваемый linux-сервер, то сотню метров конечно жално; а во-вторых не будем забывать что существует копирование при записи. Ну в крайнем случае, рестартер можно действительно на Си написать, а процесс предок мог бы перед выходом его вызывать с параметром pid своего дочернего процесса (демона).

> В этом смысле удобнее было бы наличие ключей --daemon (для открепления от стандартных дескрипторов), --restart (супервизор),

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

> и --lock (для блокирования вторых версий) у SBCL.

В смысле запрета на второй экземпляр демона?


LinkFly - 18.03.2011 14:15
@2009-2013 lisper.ru