Jak powiedzieć rsyslog, aby utworzył plik dziennika, jeśli go nie ma?

12

Domyślnym zachowaniem rsyslog jest dołączanie śladów do istniejącego pliku dziennika.

Teraz widziałem (CentOs, Scientific Linux), że gdy rsyslog już działa, usuwasz plik dziennika (np. Ten przeznaczony do śledzenia śladów z twojej aplikacji), następnie uruchamiasz aplikację, rsyslog nie utworzy pliku dziennika i żaden ślad nie zostanie zarejestrowany.

Czy istnieje jakaś opcja konfiguracji, która może powiedzieć rsyslogowi, aby utworzył plik dziennika, jeśli nie istnieje przed dołączeniem do niego śladów?

Uwaga : wykonanie service rsyslog restartspowoduje wymuszenie utworzenia pustego pliku dziennika.

rsyslog.conf (nic do niego nie dodano)

# rsyslog v5 configuration file

# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

#### MODULES ####

$ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
#$ModLoad immark  # provides --MARK-- message capability

$SystemLogRateLimitInterval 1
$SystemLogRateLimitBurst 50000

# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514


#### GLOBAL DIRECTIVES ####

# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not required,
# not useful and an extreme performance hit
#$ActionFileEnableSync on

# Include all config files in /etc/rsyslog.d/
$IncludeConfig /etc/rsyslog.d/*.conf


#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;local1.none    /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log

# ### begin forwarding rule ###
# The statement between the begin ... end define a SINGLE forwarding
# rule. They belong together, do NOT split them. If you create multiple
# forwarding rules, duplicate the whole block!
# Remote Logging (we use TCP for reliable delivery)
#
# An on-disk queue is created for this action. If the remote host is
# down, messages are spooled to disk and sent when it is up again.
#$WorkDirectory /var/lib/rsyslog # where to place spool files
#$ActionQueueFileName fwdRule1 # unique name prefix for spool files
#$ActionQueueMaxDiskSpace 1g   # 1gb space limit (use as much as possible)
#$ActionQueueSaveOnShutdown on # save messages to disk on shutdown
#$ActionQueueType LinkedList   # run asynchronously
#$ActionResumeRetryCount -1    # infinite retries if host is down
# remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional
#*.* @@remote-host:514
# ### end of the forwarding rule ###
fduff
źródło
Czy możesz udostępnić plik .conf?
slm

Odpowiedzi:

10

Z POV rsyslog usunięty plik dziennika nadal istnieje. Wynika to z faktu, że rsyslog nie zapisuje do nazwy pliku, tylko zapisuje uchwyt pliku, który otworzył dla pliku dziennika.

Systemy uniksowe nie usuwają pliku, dopóki nie będzie żadnych procesów z otwartymi uchwytami do pliku. Oznacza to, że miejsce na dysku używane przez usunięty plik nie jest zwalniane, dopóki wszystkie otwarte uchwyty plików nie zostaną zamknięte. Oznacza to również, że wszelkie procesy z otwartymi uchwytami pliku dla usuniętego pliku mogą kontynuować czytanie i / lub zapisywanie do pliku.

Wysłanie sygnału HUP (np. Przez pkill -HUP rsysloglub /etc/init.d/rsyslog rotate) do rsyslog nakazuje mu zamknięcie wszystkich otwartych plików, przeładowanie pliku konfiguracyjnego i ponowne otwarcie wszystkich plików dziennika do zapisu (tworzenie ich, jeśli to konieczne).

Ponowne uruchomienie rsyslogd również działa.

Zauważ, że jest to funkcja, a nie błąd, z pewnymi przydatnymi implikacjami - np. Dlatego rsyslog zapisuje do tego samego pliku dziennika nawet po jego obróceniu (tj. Zmianie nazwy / mv-ed), dopóki rsyslog nie otrzyma sygnału HUP. Oznacza to, że skrypty i narzędzia do przetwarzania dzienników nie muszą skrupulatnie uważać na czas - mogą po prostu obracać wszystkie dzienniki, wysyłać rsyslog HUP i wszystko działa dalej, bez utraty danych dziennika.

BTW, jedynym sposobem, aby tak się nie stało z rsyslog, byłoby zamknięcie i ponowne otwarcie każdego pliku dziennika przy każdym zapisie (lub przynajmniej wywołaniu sync()). Wydajność byłaby fatalna.

cas
źródło
Czy wiesz od razu, czy zabicie -HUP do rsyslog spowoduje, że zacznie zapisywać do nowego pliku?
slm
masz na myśli, jeśli rsyslog.conf zmienił się i zdefiniowano nowy plik dziennika? tak, na pewno utworzy i zacznie pisać do nowego pliku po otrzymaniu HUP ... to jest część tego, że ponownie ładuje konfigurację.
cas
OK, to właśnie zasugerowałem w mojej trzeciej metodzie, dzięki!
slm
problem polega na tym, że rsyslog jest uruchomiony, usuwasz plik dziennika aplikacji (bez ponownego uruchamiania rsyslog), a następnie nie będzie rejestrowane żadne śledzenie, ponieważ rsyslog nie utworzy pliku dziennika, jeśli go nie ma, gdy jest uruchomiony ...
fduff
1
jak powiedziałem, z POV rsyslog ten uchwyt pliku nadal istnieje. to będzie nie zamknąć i ponownie otworzyć / ponownie utworzyć pliki dziennika aż poinformować go o ponowne uruchomienie go albo z sygnałem HUP. rsyslog robi to, co mu każesz, nie więcej. co ważniejsze, problemem nie jest to, co robi rsyslog, ale twoje zrozumienie zachowania rsyslog i dlaczego tak się zachowuje.
cas
3

$ FileCreateMode

Czy ta opcja nie robi tego, co chcesz, $ FileCreateMode ?

fragment

$FileCreateMode 0600

This sample lets rsyslog create files with read and write access only for the 
users it runs under.

The following sample is deemed to be a complete rsyslog.conf:

$umask 0000 # make sure nothing interferes with the following definitions
*.* /var/log/file-with-0644-default
$FileCreateMode 0600
*.* /var/log/file-with-0600
$FileCreateMode 0644

*.* /var/log/file-with-0644

Moduł wyjściowy pliku

Zgodnie z dokumentacją rsyslog do tego celu można użyć argumentu File modułu File Output.

fragment omfile module

Plik

Jeśli plik już istnieje, dodawane są do niego nowe dane. Istniejące dane nie są obcinane. Jeśli plik jeszcze nie istnieje, jest tworzony. Pliki są otwarte tak długo, jak długo rsyslogd jest aktywny. Jest to sprzeczne z rotacją zewnętrznego pliku dziennika. Aby zamknąć plik po obrocie, wyślij rsyslogd sygnał HUP po obróceniu pliku.

Wyślij syslog sygnał HUP

Myślę, że ostatecznie musisz „uruchomić” rsyslog, aby to zrobić. Nie sądzę, że będzie to, co chcesz automatycznie. Możesz więc dać mu sygnał HUP, aby uruchomić ponowne tworzenie pliku dziennika po jego usunięciu.

$ sudo pkill -HUP rsyslog

W ten sposób utworzyłem następujące komunikaty w moim /var/log/messagespliku dziennika:

Sep 26 15:16:17 grinchy rsyslogd: [origin software="rsyslogd" swVersion="4.6.3" x-pid="1245" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Sep 26 15:16:44 grinchy rsyslogd: [origin software="rsyslogd" swVersion="4.6.3" x-pid="1245" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
slm
źródło
Nie, użyłem go do ustawienia uprawnień do plików i to działa dobrze. Problem polega na tym, że jeśli plik dziennika został usunięty, syslog nie będzie próbował go utworzyć przed zarejestrowaniem msg.
fduff
Został usunięty, a serwer nie został ponownie uruchomiony?
slm
dokładnie. Robię testy i natknąłem się na tę specyfikę ...
fduff,
@fduff - zobacz moje aktualizacje, wypróbuj trzeci!
slm