проброс консоли cmd.Cmd

Переделай его в какой-нить SimpleXMLRPCServer, например.

Сделай 2 thread один основной второй который будет слушать какой нить порт для приёма клмманд. Только я не понял зачем ты использовал cmd.cmd изначально

unix socket.

Можешь посмотреть как это в fail2ban сделано, как прмер...

Только я не понял зачем ты использовал cmd.cmd изначально

а что по-твоему можно было еще использовать? как иначе общаться с демоном? это очень хороший модуль, он удивительно простой и полезный. для демонов в первую очередь - можешь через неделю подключиться tmux'ом и что-то ему скомандовать, что-то спросить. а иначе это «черный ящик» с логами. это и quick and dirty пока разрабатываешь и после сдачи заказчику даже удобно

смотри, тебе вот надо какое-то действие ты просто заводишь команду и всё - 2 минуты. (если хочешь наворочнные ключи, то разбираешь argparse.)

Сделай 2 thread один основной второй который будет слушать

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

вот для примера

powcycle device 14 --timeout=25 --acquire-or-schedule

ты имеешь в виду реимлементировать все команды под XMLRPC? как-то не оч...

если на то пошло, то у меня уже есть http интерфейс с простелькой панелью + json для потребления, но им пользуется конечный пользователь и там команд меньше разумеется. в т.ч. и потому, что у меня уже в консоли есть команды которые управляют http-сервером

unix socket

ну вот я тоже так подумал, только вот как скрестить его с cmd.Cmd. видимо нужно слепить какой-то свой мини-протокол.

спасибо за наводку про fail2ban

Вот тут есть подобное https://pypi.python.org/pypi/rpdb/0.1.1

Вообще я подумал можно сделать mkfifo и заменить stdin/stdout этим fifo, но там свои тонкости. Например, он вроде блокирует процесс по дефолту, пока этот файл не откроешь.

Ээ ну у cmd.Cmd вроде ты задаешь методы типа do_something(param)? Если просто заменить это на xmlrpc у тебя будет там метод do_something тоже с одним параметром, который ты так же разберешь. Но я не подумал как быть с выводом, придется print заменить на return.

т.е. получается попробовать превратить stdin/stdout в сокет, а потом обратно на том конце. интересно.

ну да, так и есть. принты заменить не проблема.

можешь через неделю подключиться tmux'ом и что-то ему скомандовать, что-то спросить. а иначе это «черный ящик» с логами.

Ну демон в общем-то и есть «черный ящик» с логами. Т е если я правильно понимаю у тебя этот «демон» запускается из терминала и висит в ней в виде запущеного интерактивного shell cmd.cmd ? И ты подключаясь к этому shell можешь вводить команды ? Ну а тогда это не «демон», ибо «Де́мон (daemon, dæmon, др.-греч. δαίμων божество) — компьютерная программа в системах класса UNIX, запускаемая самой системой и работающая в фоновом режиме без прямого взаимодействия с пользователем».

Ну демон в общем-то и есть «черный ящик» с логами

глупость

Ну а тогда это не «демон», ибо
работающая в фоновом режиме без прямого взаимодействия

пургу гонишь вообще. 1) как она запускается совершенно не важно 2) демон может взаимодействовать с пользователем

ты подключаясь к этому shell можешь вводить команды
тогда это не «демон»

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

демон это программа которая

• в целом не имеет собственного критерия остановки (исчерпания работы)
• способна сама находить себе работу / или ждать работы и принимать нечто в работу (соединения, события, whatever)

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

моя программа:

• месяцами работает с железками и сама знает что с ними делать, в плоть до power-cycle
• реагирует на изменения в конфигрурации системы
• мониторинг и watchdogи на железки и другие программы
• запускает, следит и управляет другими процессами
• имеет внутренний планировщик

имеет три интерфейса

• сигналы
• встроенную http-панель
• встроенную консоль

приходится использовать другие программы

ты бы тред перечитал, хотя ты тупой видимо.

http://alittlebit.ru/upload/iblock/eea/22577c07a859daa4ac0d90e22f7686a2.jpeg

мне тебя даже не жаль

Я смотрю вы большой специалист в системном программировании, хотя недавно говорили «я ничего не знаю ни о С++ или даже о С».

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

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

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

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

полный бред это вы и ваши рассуждения. и вот почему:

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

2) консольный ввод для моей программы совершенно опционален (оба ключа и --interactive и --http опциональны), возник как скаффолдинг в процессе разработки, т.к. одних логов для диагностики иницииации событий было недотаточно. если любой интерфейс опционален - то это демон. Так кто тут бред несет, а?

надо было сразу команды из сокета принимать

- программа вообще не нуждается командах от пользователя, она может работать и так

если оно так уж понадобилось, осуществлять через этот же сокет

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

и заявляете, что это у вас демон

да еще раз заявляю, что у меня это демон, а ваши доводы называю бредом.

«я ничего не знаю ни о С++ или даже о С».

по прежнему. и не вижу противоречий.

Я смотрю вы большой специалист в системном программировании

ни разу. а ваши намеки не в тему, т.к. не надо быть системным программистом чтобы понимать, что «демон» таки может иметь интерфейс, если он от него не зависит.

это тред не читай@сразу кукарекай? или неспособность к восприятию текста уже?

демон должен обладать каким-то удалённым управлением, ежели оно нужно

читай выше, мой демон обладает удаленным. по интернету даже

ежели оно нужно

но при он этом не зависит от него.

и еще обладает консольным, но тоже не зависит от него. более того при запуске из под systemd я ему ключик --ineractive не передаю, т.е. даже системд не может им насладиться.

не укладывается в голове всё равно? ну ладно.