Хотелось поставить на роутер в минималистичном варианте - однако поскольку сам z-agent - консольная программа, для его запуска в фоне как служны нужно что-нибудь вроде screen/nohup. + логи идут в stdout либо в файл. Первый вариант в случае службы - отпадает. Второй вариант - тоже не очень хорош, покуда память на роутере вообще ограничена.
В общем - подправил агента, вот патч:
http://pastebin.com/gR4mvQqq
Изменений два:
1. Можно указать pid-файл в качестве параметра -b/-B/--pid (см. запуск -help - подскажет). Использование этого параметра автоматически означает, что мы хотим запустить агента как демона. При этом он автоматически отключится от консоли и управляющей сессии, и уйдёт в фон. Свой pid при этом он запишет в указанный файл. Лог (если не задан явно) - см. ниже.
2. Можно указать в качестве лога - 'syslog'. Это можно сделать явно, либо - если запускаем агента как демона - syslog делается логом по умолчанию (вместо stdout в случае консольного запуска).
Чуть позже выложу управляющий скрипт для OpenWRT - который завершает z-agent в целостную службу-демон (с задачей параметров яерез icu, автостартом при загрузке и прочими стандартными плюшками служб OpenWRT).
contribute: подрихтовал немного z-agent
Благодарим за полезный патч!
Огромное спасибо за участие в улучшении проекта!
Мы проверим Ваш патч на предмет взаимодействия с Z-Connector.exe и на предмет портабельности и включим его в официальную версию.
На всякий случай (хотя, вроде, Вы это учли), Z-Agent.exe (собирается из тех же исходников по Windows) отправляет данные в stdout, а Z-Connector.exe (графическая оболочка) их анализирует для предоставления правильного GUI. Т.е. stdout нужен. Вы пробовали эту связку на винде?
Мы проверим Ваш патч на предмет взаимодействия с Z-Connector.exe и на предмет портабельности и включим его в официальную версию.
На всякий случай (хотя, вроде, Вы это учли), Z-Agent.exe (собирается из тех же исходников по Windows) отправляет данные в stdout, а Z-Connector.exe (графическая оболочка) их анализирует для предоставления правильного GUI. Т.е. stdout нужен. Вы пробовали эту связку на винде?
Вроде окружил всё условной компиляцией.
На винде ничего поменяться не должно.
Единственное изменение поведения в "нормальной" ситуации - если в качестве лога задать "syslog" - то непатченная версия будет просто журналировать в файл с таким именем (независимо от платформы). А патченная на винде ругнётся, а не на винде будет слать всё демону syslog.
А вот режим демона оказался не столь нужен. Уже после изменений я вдруг осознал, что start-stop-daemon в init-скрипте всё нужное делает сам, включая управление pid-файлом. В общем - он имеет смысл только если заморочиться полностью stand-alone вариантом.
Init-скрипт вот такой:
http://pastebin.com/8Kb5ktAU
Единственное изменение поведения в "нормальной" ситуации - если в качестве лога задать "syslog" - то непатченная версия будет просто журналировать в файл с таким именем (независимо от платформы). А патченная на винде ругнётся, а не на винде будет слать всё демону syslog.
А вот режим демона оказался не столь нужен. Уже после изменений я вдруг осознал, что start-stop-daemon в init-скрипте всё нужное делает сам, включая управление pid-файлом. В общем - он имеет смысл только если заморочиться полностью stand-alone вариантом.
Init-скрипт вот такой:
http://pastebin.com/8Kb5ktAU
Да и функция syslog не очень
Да и функция syslog не очень нужна, т.к. можно просто прогнать всё через пайп:Run_Z-Agent.sh | logger -t Z-Connector Если нет logger, то можно| nc -w0 -u 127.0.0.1 514Принцип Unix: собираем большую систему и змельчайших кирпичиков.
Здесь уже нужно искать разумную границу.
Можно и весь коннектор переписать на чистом bash . Только зачем?
logger - это + ещё один постоянно висящий в памяти процесс (мы ведь демона пускаем, а не разовый консольный скрипт). При том, что его единственная цель - внутри себя вызвать syslog, такая оболочка вокруг (в виде отдельного процесса и пайпа) кажется лишней.
(на "большом брате" может и нормально, а вот на embedded system, где ресурсы очень немногочислены - уже спорно).
(а вообще unix-way относительно логов для относительно немногословных программ - это как раз кидать абсолютно всё в syslog. И рулить потом по разным файлам (если нужно) уже на его стороне. И только при большом потоке сообщений (например - лог всех обращений к веб-серверу) делают отдельный файл, чтоб не флудить на демона).
С nc то же самое, + к тому же он установлен далеко не на каждой системе.
logger - это + ещё один постоянно висящий в памяти процесс (мы ведь демона пускаем, а не разовый консольный скрипт). При том, что его единственная цель - внутри себя вызвать syslog, такая оболочка вокруг (в виде отдельного процесса и пайпа) кажется лишней.
(на "большом брате" может и нормально, а вот на embedded system, где ресурсы очень немногочислены - уже спорно).
(а вообще unix-way относительно логов для относительно немногословных программ - это как раз кидать абсолютно всё в syslog. И рулить потом по разным файлам (если нужно) уже на его стороне. И только при большом потоке сообщений (например - лог всех обращений к веб-серверу) делают отдельный файл, чтоб не флудить на демона).
С nc то же самое, + к тому же он установлен далеко не на каждой системе.
Соглашусь. Мы поставили эту
Соглашусь. Мы поставили эту доработку в очередь. Хотя с нашей загрузкой нам месяцев 5-6 нужно, чтоб добраться до этого пункта в списке ;(