Регистрация демонов в Linux - PullRequest
64 голосов
/ 01 октября 2008

Итак, у меня есть демон, работающий в системе Linux, и я хочу получить отчет о его действиях: журнал. Вопрос в том, как лучше всего это сделать?

Моя первая идея - просто открыть файл и записать в него.

FILE* log = fopen("logfile.log", "w");
/* daemon works...needs to write to log */
fprintf(log, "foo%s\n", (char*)bar);
/* ...all done, close the file */
fclose(log);

Что-то не так с логированием? Есть ли лучший способ, например, какой-нибудь фреймворк, встроенный в Linux?

Ответы [ 10 ]

97 голосов
/ 01 октября 2008

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

man 3 syslog

и вы получите справку по интерфейсу C к нему.

Некоторые примеры

#include <stdio.h>
#include <unistd.h>
#include <syslog.h>

int main(void) {

 openlog("slog", LOG_PID|LOG_CONS, LOG_USER);
 syslog(LOG_INFO, "A different kind of Hello world ... ");
 closelog();

 return 0;
}
22 голосов
/ 01 октября 2008

Этот , вероятно, будет , был скачкой, но да, средство системного журнала, которое существует в большинстве, если не во всех Un * x, является предпочтительным способом. Нет ничего плохого в том, чтобы войти в файл, но это оставляет на ваших плечах ряд задач:

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

Системный журнал заботится обо всем этом, и даже больше, о вас. API похож на клан printf, поэтому у вас не должно возникнуть проблем с адаптацией кода.

11 голосов
/ 01 октября 2008

Еще одно преимущество syslog в более крупных (или более защищенных) установках: демон syslog можно настроить на отправку журналов на другой сервер для записи туда вместо (или в дополнение к) локальной файловой системы.

Гораздо удобнее хранить все журналы для вашей фермы серверов в одном месте, чем читать их отдельно на каждой машине, особенно когда вы пытаетесь сопоставить события на одном сервере с событиями на другом. А когда кто-то взломан, вы больше не можете доверять его журналам ... но если сервер журналов остался защищенным, вы знаете, что из его журналов ничего не будет удалено, поэтому любая запись о вторжении останется без изменений.

8 голосов
/ 01 октября 2008

Я выкладываю много сообщений от daemon на daemon.info и daemon.debug, когда тестирую модули. Строка в вашем syslog.conf может вставить эти сообщения в любой файл, который вы хотите.

http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/040/4036/4036s1.html содержит лучшее объяснение API C, чем справочная страница, imo.

2 голосов
/ 01 октября 2008

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

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

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

Я бы дал ссылку на хороший код для этого, но у меня его нет. Я просто хочу один. :)

2 голосов
/ 01 октября 2008

Syslog - хороший вариант, но вы можете рассмотреть возможность просмотра log4c. Платформы log4 [что-то] хорошо работают в своих реализациях на Java и Perl и позволяют вам - из файла конфигурации - выбирать запись в системный журнал, консоль, плоские файлы или определенные пользователем средства записи журнала. Вы можете определить конкретные контексты журнала для каждого из ваших модулей, и иметь каждый контекстный журнал на различном уровне, как определено вашей конфигурацией. (трассировка, отладка, информация, предупреждение, ошибка, критическое состояние), и пусть ваш демон на лету перечитывает этот файл конфигурации, перехватывая сигнал, позволяя вам манипулировать уровнями журнала на работающем сервере.

2 голосов
/ 01 октября 2008

Как указано выше, вы должны заглянуть в системный журнал. Но если вы хотите написать свой собственный код регистрации, я бы посоветовал вам использовать режим «a» (написать приложение) fopen.

Несколько недостатков написания собственного кода журналирования: обработка ротации журналов, блокировка (если у вас несколько потоков), синхронизация (хотите дождаться записи журналов на диск?) Одним из недостатков системного журнала является то, что приложение не знает, записаны ли журналы на диск (возможно, они были потеряны).

1 голос
/ 26 сентября 2013

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

1 голос
/ 02 октября 2008

Наша встроенная система не имеет системного журнала, поэтому демоны, которые я пишу, выполняют отладку в файл, используя режим открытия "a", аналогичный описанному вами. У меня есть функция, которая открывает файл журнала, выплевывает сообщение, а затем закрывает файл (я делаю это только тогда, когда происходит что-то неожиданное). Однако мне также пришлось написать код для обработки ротации журналов, как упоминали другие комментаторы, который состоит из 'tail -c 65536 logfile> logfiletmp && mv logfiletmp logfile'. Он довольно грубый и, возможно, его следует называть «журналом фронтальных усечений», но он не дает нашей файловой системе на основе небольшого RAM-диска заполниться файлом журнала.

0 голосов
/ 01 октября 2008

Существует множество потенциальных проблем: например, если диск заполнен, хотите ли вы, чтобы ваш демон вышел из строя? Кроме того, вы будете перезаписывать свой файл каждый раз. Часто кольцевой файл используется для того, чтобы на вашем компьютере было выделено место для файла, но вы можете хранить достаточно истории, чтобы быть полезной, не занимая слишком много места. Есть инструменты, такие как log4c, которые вы можете помочь вам. Если ваш код c ++, то вы можете рассмотреть log4cxx в проекте Apache (apt-get install liblog4cxx9-dev в ubuntu / debian), но похоже, что вы используете C.

...