Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как демонизировать perl скрипт с дочериным процессами?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Мне нужна определенная структура. Нужен демон управления, который постоянно контролирует базу данных для задач и контролирует дочерних демонов. Демон управления должен назначать задачи для дочерних демонов, контролировать задания, создавать новых детей, если один из них умрет, и т.д. Демоны дети проверяют базу данных на задачи для них (по PID). Каким способом мне это реализовать?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

З ходу видно (і вже згадували), що задачу треба розбити мінімум на дві частини з «прошарком» між ними.
А то отримаєш такого монстра потім, що замахашся тестить, відловлювати баги, дебажить і т.п.

Переформулируй вопрос. Прямой ответ на твой вопрос это man Proc::Daemon но кажется это не то что ты имел ввиду.

ну в моем дистрибутиве перловые доки были проэкспортированы в man-ы :)

Proc::Daemon
подходит, но может ли сам демонизатор сделать демоном? Или опять же скрипт демонизации демонизировать другим скриптом? Как не красиво предложение получилось)

> подходит, но может ли сам демонизатор сделать демоном?

без проблем если я правильно понял вопрос

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

Там же. Секция METHODS:

If you call the Init method in the context without looking for a return value (void context) the parent process will exit here like in earlier versions:

Proc::Daemon::Init();

И да — прочитайте Уильма Ричарда Стивенса все что сможете найти.

Как человек, который пишет на perl с 1997-года достаточно много и постоянно, могу сказать, что изначально неправильно поставлена архитектура. Зачем контролировать базу данных детям, если задачи можно и нужно передавать через механизм очередей: rabbitmq, zeromq ? Запускается один демон, который контролирует падение дочернего процесса через SIGCHLD. Таких процессов может быть множество.
Задачи передаются через rabbitmq. Офигенно классный инструмент.
Можно заюзать и AnyEvent. Вообще класс.

А как человек, который второй год плотно пишет на Erlang, я бы скелет вышеописанной задачи за час нарисовал бы точно. Там это все «из коробки».

Плюсую AnyEvent::Fork.

Для чего нужны такие сложности, страшно представить. Похожие задачи всегда решал другим путем: очередь, планировщик очереди, ферма равноправных воркеров (WEB-сервер в prefork-mode раздает задачи свободным воркерам, REST API для планировщика задач).

В теории нужно перед форком делать socketpair и один конец отдавать в дочерний процесс и дальше уже через него RPC делать, посмотри AnyEvent::Fork::RPC.

Согласно Stackoverflow Driven Development:

stackoverflow.com/...daemon-in-linux

и как-нибудь так:
stackoverflow.com/...ocesses-in-perl

Это я все видел, но не видел примеров похожих на мой. Мне нужны дочерные демоны которые отличается от родителя, который контролирует их деятельность.

Я уже забыл все ужасы perl, но быстрый гугл дает такие варианты:
perldoc.perl.org/IPC/Open2.html
типа получил pid, process stdout, stderr и контролируй сколько хочешь.

не знаю, что-то мне эта либа не нравится...

мне вообще perl не нравится.

WTF is Stackoverflow Driven Development?
чувство юмора заценил!

ну а что, если подумать, то 30% работы можно решать особо не вдумываясь, используя SO :) *

* - в отдельных случаях, может достигать 80%

представляю если бы девелоперам запретили пользоваться интернетом — вся работа бы остановилась :-)))). кстати, у меня был опыт работы конторе в которой интернет был запрещен (не вообще, а конкретно на девелоперских компах). разные бывают тараканы у руководства

ну работали же в 90-х люди.

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

Есть одно место куда я по утрам заглядываю на подработку, так там стоит фаервол который парсит все что связано с «/работа.../» или «/work...» etc и нагло блочит. Так что половина кейсов на SOF не открывается))

Підписатись на коментарі