Регистрация Daemon в Linux

Question

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

Answer 1

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

man 3 syslog 

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

Someexamples

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

Answer 9

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

Answer 10

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