Come dire a rsyslog di creare il file di registro se non c'è?


12

Il comportamento predefinito di rsyslog è di aggiungere tracce a un file di registro esistente .

Ora, ho visto (CentOs, Scientific Linux) che quando rsyslog è già in esecuzione, si elimina il file di registro (ad esempio quello dedicato alle tracce di registro dall'applicazione), quindi si esegue l'applicazione, rsyslog non creerà un file di registro e nessuna traccia verrà registrata.

Esiste in qualche modo un'opzione di configurazione che può dire a rsyslog di creare un file di registro se non è presente prima di aggiungere tracce?

Nota : l'esecuzione service rsyslog restartforzerà la creazione di un file di registro vuoto.

rsyslog.conf (niente aggiunto ad esso)

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

Puoi condividere il tuo file .conf?
slm

Risposte:


10

Dal POV di rsyslog, il file di registro eliminato esiste ancora. Questo perché rsyslog non sta scrivendo sul nome del file, sta scrivendo sull'handle del file che ha aperto per il file di registro.

I sistemi Unix non eliminano effettivamente un file fino a quando non ci sono processi con handle aperti nel file. Ciò significa che lo spazio su disco utilizzato dal file eliminato non viene liberato fino alla chiusura di tutti gli handle di file aperti. Significa anche che tutti i processi con handle di file aperti sul file eliminato possono continuare a leggere e / o scrivere sul file.

L'invio di un segnale HUP (ad esempio tramite pkill -HUP rsyslogo /etc/init.d/rsyslog rotate) a rsyslog gli dice di chiudere tutti i suoi file aperti, ricaricare il suo file di configurazione e riaprire tutti i file di registro per la scrittura (crearli se necessario).

Anche il riavvio di rsyslogd funziona.

Si noti che questa è una funzione, non un bug, con alcune implicazioni utili - ad es. È per questo che rsyslog continua a scrivere nello stesso file di registro anche dopo che è stato ruotato (ovvero rinominato / mv-ed) fino a quando rsyslog riceve un segnale HUP. Ciò significa che gli script e le utilità di elaborazione dei registri non devono essere scrupolosamente attenti ai tempi: possono semplicemente ruotare tutti i registri, inviare a rsyslog un HUP e tutto continua a funzionare, senza perdita di dati di registro.

A proposito, l'unico modo in cui ciò non accada con rsyslog sarebbe quello di chiudere e riaprire ogni file di registro su ogni scrittura (o almeno chiamato sync()). Le prestazioni sarebbero spaventose.


Sai fuori mano se un kill -HUP a rsyslog lo attiverà per iniziare a scrivere su un nuovo file?
slm

vuoi dire, se rsyslog.conf è cambiato e c'è un nuovo file di registro definito? sì, sicuramente creerà e inizierà a scrivere sul nuovo file alla ricezione di un HUP ... fa parte del punto di ricaricare la configurazione.
CAS

OK, questo è quello che ho suggerito nel mio terzo metodo, grazie!
slm

il problema è che rsyslog è in esecuzione, si elimina un file di registro dell'applicazione (senza riavviare rsyslog) e quindi non verrà più tracciata poiché rsyslog non creerà il file di registro se non è presente mentre è in esecuzione ...
fduff

1
come ho detto, dal POV di rsyslog, esiste ancora quell'handle di file. lo farà non chiudere e riaprire / ri-creare i file di registro fino a quando gli si dice di riavviando o con un segnale HUP. rsyslog fa quello che gli dici di fare, non di più. ancora più importante, il problema non sta nel comportamento di rsyslog, ma nella comprensione del comportamento di rsyslog e del perché si comporti in questo modo.
Cas

3

$ FileCreateMode

Questa opzione non fa quello che vuoi, $ FileCreateMode ?

estratto

$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

Modulo di output file

Secondo la documentazione di rsyslog, l'argomento File del Modulo di output file potrebbe essere utilizzato per fare ciò.

estratto del modulo omfile

File

Se il file esiste già, vengono aggiunti nuovi dati. I dati esistenti non vengono troncati. Se il file non esiste già, viene creato. I file rimangono aperti fino a quando rsyslogd è attivo. Ciò è in conflitto con la rotazione del file di registro esterno. Per chiudere un file dopo la rotazione, inviare a rsyslogd un segnale HUP dopo che il file è stato ruotato.

Invia a syslog un segnale HUP

Penso che alla fine sia necessario "attivare" rsyslog per farlo. Non penso che farà quello che vuoi automaticamente. Quindi potresti dargli un segnale HUP per innescare la ricostruzione del file di registro dopo che è stato eliminato.

$ sudo pkill -HUP rsyslog

In questo modo ho creato i seguenti messaggi nel mio /var/log/messagesfile di registro:

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'.

No, l'ho usato per impostare le autorizzazioni per i file e funziona perfettamente. Il problema è che se il file di registro è stato rimosso, syslog non tenterà di crearlo prima di registrare msg.
fduff,

È stato eliminato e il server non è stato riavviato?
slm

Esattamente. Sto facendo dei test e mi sono imbattuto in questa particolarità ...
fduff,

@fduff - guarda i miei aggiornamenti, prova il terzo!
slm
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.