Помогите новичку!!! Одна программа (сервер) должна логировать свою работу, а другая, независимая от нее, отображать лог-файл в графическом окне. Известны только имена процессов. Подайте какую-нибудь идею.
>Помогите новичку!!! Одна программа (сервер) должна логировать свою работу, а другая, независимая
>от нее, отображать лог-файл в графическом окне. Известны только имена процессов.
>Подайте какую-нибудь идею.
а имя log файла известно?
>а имя log файла известно?известно, но я думала может записывать в файл FIFO или отправлять по UDP протоколу, но можно и в файл, но как отслеживать появление новых сообщений?
>
>>а имя log файла известно?
>
>известно, но я думала может записывать в файл FIFO или отправлять по
>UDP протоколу, но можно и в файл, но как отслеживать появление
>новых сообщений?
если будешь писать в лог-файл то читать можно так: xterm -e tail -f лог-файл
>
>>а имя log файла известно?
>
>известно, но я думала может записывать в файл FIFO или отправлять по
>UDP протоколу, но можно и в файл, но как отслеживать появление
>новых сообщений?классический UNIX/Linux подход
сервер пишет сообщения : man 2 syslog
читать: под Х есть смотрелки графические
если охота самой написать то 2 способа
1) аналог tail -f /var/log/messages | grep MY_NAME_OF_PROC
2) server_prod -> syslogd -> фильтрация по имени и вывод в fifo -> читалка читает из фифо
аналог tail - надо написать скрипт?
и есть пример server_prod?
>аналог tail - надо написать скрипт?можно и через скрипт,
но второй вариант лучше, хотя придется дополнительно /etc/syslog.conf править>и есть пример server_prod?
это очепятка s/server_prod/server_prog/
==================================================
#include <syslog.h>openlog(PRNAME " v" VERSION, LOG_PID , LOG_DAEMON);
...
syslog(LOG_INFO,"my pid %d", getpid());
...
syslog(LOG_ERR,"function %s failed with %m", my_func);
...
closelog();
=================================================Документации по syslog - море.
Главное с пути не сбится и придерживаться классических подходов.
>Главное с пути не сбится и придерживаться классических подходов.IMHO, не всегда классический подход является лучшим. Успеха добивается тот, кто идет по тропе, которой еще никто до него не ходил. Нужно искать новые, лучшие решения, иначе прогресса не видать.
P.S.: к конкретному случаю мой пост, конечно, никак не относится.
>IMHO, не всегда классический подход является лучшим. Успеха добивается тот, кто идет
>по тропе, которой еще никто до него не ходил. Нужно искать
>новые, лучшие решения, иначе прогресса не видать.Тиха украинская ночь, но сало надо перепрятать.
>>syslogd -> фильтрация по имени и вывод в fifo -> читалка читает из фифо
все это здорово, но файл FIFO должен быть создан и открыт до запуска демона syslogd, а моя прога запускается когда захочу. Мне каждый раз перезапускать syslogd? Может есть еще какие-нибудь решения?
Я уже думала, может по UDP самой себе слать сообщения, и не пользоваться syslog.
>>>syslogd -> фильтрация по имени и вывод в fifo -> читалка читает из фифо
>все это здорово, но файл FIFO должен быть создан и открыт до
>запуска демона syslogd, а моя прога запускается когда захочу. Мне каждый
>раз перезапускать syslogd? Может есть еще какие-нибудь решения?
>Я уже думала, может по UDP самой себе слать сообщения, и не
>пользоваться syslog.
Можно настроить syslog чтобы слал на определенный хост свой лог, вовсе не обязательно в fifo.
простых путей решения как вижу нет. Легко записать syslog-ом а прочитать...
>простых путей решения как вижу нет. Легко записать syslog-ом а прочитать...А что должно происходить когда программа чтения не запущена? Должны ли сообщения куда-то складываться?
>>>syslogd -> фильтрация по имени и вывод в fifo -> читалка читает из фифо
>все это здорово, но файл FIFO должен быть создан и открыт до
>запуска демона syslogd, а моя прога запускается когда захочу. Мне каждый
>раз перезапускать syslogd? Может есть еще какие-нибудь решения?
>Я уже думала, может по UDP самой себе слать сообщения, и не
>пользоваться syslog.Да зачем тут FIFO. Берешь CORBA (ACE, детище мистера Шмидта, http://www.cs.wustl.edu/~schmidt/ACE.html), строишь систему сбора логов от твоих программ. Из своей программы получаешь доступ к своему сервису сбора логов, и пишешь логи туда. А он там пусть отображает, что хочет.
Можно и по UDP рассылать, а сервер пусть получает и обрабатывает.
Можно писать в файл, например. Посмотри библиотеки log4cpp, к примеру. Только в этом случае твой сборщик мусора (пардон, логов), должен будет знать, сколько у тебя программ и в какие файлы они пишут логи.
А можно инфраструктуру на базе TCP/IP. Берешь, к примеру, тот же ACE, используешь асинхронные сокеты, и вперед.
Есть еще вариант, писать логи, скажем, в SQL server. Читать из базы можно, используя polling, а можно notification service заюзать. Если совсем будет нечего делать - Extended Stored Procedure напиши, которая будет вызываться по триггеру и рассылать нотификацию по UDP, скажем.
Если все вместе собрать, то получится так.
1) Берем log4cpp, добавляем туда свой appender, который будет писать логи в RDBMS.
2) Добавляем в RDBMS свою extended stored procedure, которая используя UDP будет сообщать об обновлениях данных.
3) Строим свой CORBA сервера, который будет получать нотификации из SQL сервера (по UDP), и обновлять данные о логах.
4) Пишем клиента для своего сервера, который будет уже по CORBA ходить на сервер за логами.Ах да, забыл.. Очень важно настроить репликацию на SQL сервере, чтобы логи вдруг не потерялись (тиха Украинская ночь, но мало ли машина взорвется). Сервер, работающий с базой, тоже должен быть кластеризирован, причем multi master вполне подойдет.
В итоге есть у нас и MODEL, и controller, а view пиши как хочешь, вот тебе и QT, и GTK, и ncurses.
Все просто.
> IMHO, не всегда классический подход является лучшим.
> Успеха добивается тот, кто идет по тропе,
> которой еще никто до него не ходил.
> Нужно искать новые, лучшие решения, иначе > прогресса не видать.> P.S.: к конкретному случаю мой пост, конечно, никак не относится.
Про классический подход говорил применительно к syslog.
А по новые пути согласен. Например: init, init-ng и очень интересный
runit - a UNIX init scheme with service supervision http://smarden.org/runit/
>Все просто.Вот уж постебался так постебался :-)