Запуск демона в Linux

Итак, у меня есть демон, работающий в системе 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?

ОТВЕТЫ

Ответ 1

У 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;
}

Ответ 2

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

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

Syslog заботится обо всем этом и многом другом. API аналогичен клану printf, поэтому у вас не должно возникнуть проблем с адаптированием кода.

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

Ответ 10

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