Comment dire à rsyslog de créer un fichier journal s'il n'est pas là?


12

Le comportement par défaut de rsyslog consiste à ajouter des traces à un fichier journal existant .

Maintenant, j'ai vu (CentOs, Scientific Linux) que lorsque rsyslog est déjà en cours d'exécution, vous supprimez le fichier journal (par exemple celui dédié à la journalisation des traces de votre application), vous exécutez ensuite votre application, rsyslog ne créera pas de fichier journal et aucune trace ne sera enregistrée.

Existe-t-il une option de configuration qui peut indiquer à rsyslog de créer un fichier journal s'il n'est pas là avant d'y ajouter des traces?

Remarque : une opération service rsyslog restartforce la création d'un fichier journal vide.

rsyslog.conf (rien n'y est ajouté)

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

Pouvez-vous partager votre fichier .conf?
slm

Réponses:


10

À partir du POV de rsyslog, le fichier journal supprimé existe toujours. En effet, rsyslog n'écrit pas dans le nom de fichier, il écrit dans le descripteur de fichier qu'il a ouvert pour le fichier journal.

Les systèmes Unix ne suppriment pas réellement un fichier tant qu'il n'y a pas de processus avec des poignées ouvertes vers le fichier. Cela signifie que l'espace disque utilisé par le fichier supprimé n'est libéré que lorsque tous les descripteurs de fichiers ouverts sont fermés. Cela signifie également que tous les processus avec des descripteurs de fichiers ouverts dans le fichier supprimé peuvent continuer à lire et / ou à écrire dans le fichier.

L'envoi d'un signal HUP (par exemple via pkill -HUP rsyslogou /etc/init.d/rsyslog rotate) à rsyslog lui dit de fermer tous ses fichiers ouverts, de recharger son fichier de configuration et de rouvrir tous les fichiers journaux pour l'écriture (en les créant si nécessaire).

Le redémarrage de rsyslogd fonctionne également.

Notez que c'est une fonctionnalité, pas un bogue, avec des implications utiles - par exemple, c'est pourquoi rsyslog continue d'écrire dans le même fichier journal même après qu'il a été tourné (c'est-à-dire renommé / mv-ed) jusqu'à ce que rsyslog reçoive un signal HUP. Cela signifie que les scripts et les utilitaires de traitement des journaux n'ont pas à être scrupuleusement attentifs au calendrier - ils peuvent simplement faire pivoter tous les journaux, envoyer à rsyslog un HUP, et tout continue de fonctionner, sans perte de données de journal.

BTW, le seul moyen pour que cela ne se produise pas avec rsyslog serait qu'il soit fermé et rouvert chaque fichier journal à chaque écriture (ou du moins appelé sync()). La performance serait épouvantable.


Savez-vous par vous-même si un kill -HUP vers rsyslog le déclenchera pour commencer à écrire dans un nouveau fichier?
slm

vous voulez dire, si rsyslog.conf a changé et qu'un nouveau fichier journal a été défini? oui, il va certainement créer et commencer à écrire dans le nouveau fichier lors de la réception d'un HUP ... cela fait partie de l'intérêt de recharger la configuration.
cas

OK, c'est ce que j'ai suggéré dans ma 3ème méthode, merci!
slm

le problème est que rsyslog est en cours d'exécution, vous supprimez un fichier journal d'application (sans redémarrer rsyslog), puis plus aucune trace ne sera enregistrée car rsyslog ne créera pas le fichier journal s'il n'est pas là pendant qu'il est en cours d'exécution ...
fduff

1
comme je l'ai dit, à partir du POV de rsyslog, ce descripteur de fichier existe toujours. il ne se fermera pas et ne rouvrira / recréera pas les fichiers journaux jusqu'à ce que vous le lui disiez en le redémarrant ou avec un signal HUP. rsyslog fait ce que vous lui demandez de faire, pas plus. plus important encore, le problème n'est pas dans ce que fait rsyslog, mais dans votre compréhension du comportement de rsyslog et pourquoi il se comporte comme ça.
cas

3

$ FileCreateMode

Cette option ne fait-elle pas ce que vous voulez, $ FileCreateMode ?

extrait

$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

Module de sortie de fichier

Selon la documentation de rsyslog, l'argument File du module de sortie de fichiers peut être utilisé pour ce faire.

extrait du module omfile

Fichier

Si le fichier existe déjà, de nouvelles données y sont ajoutées. Les données existantes ne sont pas tronquées. Si le fichier n'existe pas déjà, il est créé. Les fichiers sont ouverts tant que rsyslogd est actif. Cela entre en conflit avec la rotation du fichier journal externe. Afin de fermer un fichier après rotation, envoyez à rsyslogd un signal HUP après que le fichier a été pivoté.

Envoyer à Syslog un signal HUP

Je pense qu'en fin de compte, vous devez "déclencher" rsyslog pour ce faire. Je ne pense pas que ce sera ce que vous voulez automatiquement. Vous pouvez donc lui donner un signal HUP pour déclencher la recréation du fichier journal après sa suppression.

$ sudo pkill -HUP rsyslog

Cela a créé les messages suivants dans mon /var/log/messagesfichier journal:

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

Non, je l'ai utilisé pour définir des autorisations de fichier et cela fonctionne très bien. Le problème est que si le fichier journal a été supprimé, syslog ne tentera pas de le créer avant de se connecter msg.
fduff

Il a été supprimé et le serveur n'a pas été redémarré?
slm

exactement. Je fais des tests et je suis tombé sur cette particularité ...
fduff

@fduff - voir mes mises à jour, essayez la 3ème!
slm
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.