ログファイルがない場合にrsyslogにログファイルを作成するよう指示する方法は?


12

rsyslogのデフォルトの動作は、既存のログファイルにトレースを追加することです。

現在、rsyslogが既に実行されているときにログファイル(たとえば、アプリケーションからのトレースのログ専用)を削除し、アプリケーションを実行すると、rsyslog ログファイルを作成しません(CentOs、Scientific Linux)トレースは記録されません。

トレースを追加する前にログファイルを作成しないようにrsyslogに指示できる構成オプションはありますか?

:を実行するservice rsyslog restartと、空のログファイルが強制的に作成されます。

rsyslog.conf(何も追加されていません)

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

.confファイルを共有できますか?
slm

回答:


10

rsyslogのPOVから、削除されたログファイルはまだ存在しています。これは、rsyslogがファイル名に書き込むのではなく、ログファイルに対して開いているファイルハンドルに書き込むためです。

Unixシステムは、ファイルのハンドルが開いているプロセスがなくなるまで、実際にファイルを削除しません。つまり、削除されたファイルが使用していたディスク領域は、開いているファイルハンドルがすべて閉じられるまで解放されません。また、削除されたファイルへのファイルハンドルが開いているプロセスは、ファイルの読み取りや書き込みを継続できます。

HUPシグナルを(たとえば、pkill -HUP rsyslogまたはを介して/etc/init.d/rsyslog rotate)rsyslogに送信すると、開かれているすべてのファイルを閉じ、構成ファイルをリロードし、すべてのログファイルを書き込み用に再度開きます(必要に応じて作成します)。

rsyslogdの再起動も機能します。

これはいくつかの有用な意味を持つ機能であり、バグではないことに注意してください-たとえば、rsyslogがHUPシグナルを受信するまで、rsyslogがローテーション(名前変更/ mv-ed)された後でも同じログファイルに書き込み続ける理由です。これは、ログ処理スクリプトとユーティリティがタイミングについて細心の注意を払う必要がないことを意味します-すべてのログをローテーションし、rsyslogにHUPを送信するだけで、ログデータを失うことなくすべてが動作し続けます。

ところで、これをrsyslogで発生させない唯一の方法は、すべての書き込みですべてのログファイルを閉じて再度開いた場合(または少なくとも呼び出された場合sync())です。パフォーマンスはひどいものになります。


rsyslogへのkill -HUPが新しいファイルへの書き込みを開始するトリガーとなるかどうかを知っていますか?
slm

rsyslog.confが変更され、新しいログファイルが定義されている場合、どういう意味ですか?はい、それは間違いなく作成し、HUPを受信すると新しいファイルへの書き込みを開始します...それは設定を再ロードするポイントの一部です。
cas

OK、それが私の3番目の方法で提案したことです、ありがとう!
slm

問題はrsyslogの実行中です。アプリケーションログファイルを削除すると(rsyslogを再起動せずに)、rsyslog ログファイルを作成しないので、実行中にログファイル作成されません ...
fduff

1
私が言ったように、rsyslogのPOVから、そのファイルハンドルはまだ存在しています。それはなりません、あなたがそれを再起動するか、HUPシグナルを持つにそれを伝えるまでクローズと再オープン/ログファイルを再作成します。rsyslogは、ユーザーが指示したとおりに動作します。さらに重要なことは、問題はrsyslogの機能ではなく、rsyslogの動作と、そのように動作する理由を理解していることです。
cas

3

$ FileCreateMode

このオプションは、$ FileCreateModeの目的を果たしませんか?

抜粋

$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

ファイル出力モジュール

rsyslogの資料によると、ファイル出力モジュールのファイル引数を使用してこれを行うことができます。

omfileモジュールの抜粋

ファイル

ファイルが既に存在する場合、新しいデータが追加されます。既存のデータは切り捨てられません。ファイルがまだ存在しない場合は作成されます。rsyslogdがアクティブである限り、ファイルは開いたままになります。これは、外部ログファイルのローテーションと競合します。ローテーション後にファイルを閉じるには、ファイルがローテーションされた後にrsyslogdにHUPシグナルを送信します。

syslogにHUPシグナルを送信する

これを行うには、最終的にrsyslogを「トリガー」する必要があると思います。自動的に欲しいものになるとは思わない。したがって、ログファイルが削除された後、ログファイルの再作成をトリガーするHUPシグナルを与えることができます。

$ sudo pkill -HUP rsyslog

これにより、/var/log/messagesログファイルに次のメッセージが作成されました。

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

いいえ、ファイルのアクセス許可を設定するために使用しましたが、それは正常に機能します。問題は、ログファイルが削除された場合、syslogはmsgを記録する前にログファイルを作成しようとしないことです。
fduff

削除されており、サーバーは再起動されていませんか?
slm

丁度。私はいくつかのテストを行っていますが、この特殊性に
出くわしました...-fduff

@fduff-私のアップデートを見て、3番目のものを試してください!
slm
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.