☰

ログエラー統計の失敗：LogRotation中に権限が拒否されました。

tag-icon • tag-icon logrotate
ログエラー統計の失敗：LogRotation中に権限が拒否されました。

新しいCentOS 6.0サーバーをインストールした後、logrotateは完全に機能します。ある日、カーネルパニックのためにサーバーをハードブートする必要があり、ログの回転によりログが回転しなくなりました。

そのため、手動でログの回転を強制するために別々のcronエントリを作成し、出力をログファイルにリダイレクトし、各ファイルに対して次の行を取得しました。

rotating pattern: /home/mail3/log/popMailProcessing.log  forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home/mail3/log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied

ただし、コマンドラインから手動でログローテーションを実行すると、完全に機能します。コマンドラインで使用するコマンドは次のとおりです。

logrotate -v -f /etc/logrotate.d/mail3-logs

私のlogrotate.confファイルは次のとおりです

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

cron ジョブで logrotate が使用するログローテーションファイルは次のとおりです。

dateext
/home/mail3/log/pop.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/oc4j.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/incoming.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/mailpro.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/imap.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/outgoing.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/smtpout.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/retry.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/mailinglist.log {
        daily
        rotate 60
        copytruncate
        compress
}
/home/mail3/log/migrate.log {
        daily
        rotate 60
        copytruncate
        compress
}

私のcrontabエントリは次のとおりです。

03 00 * * * root /usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log

SELinuxが実施されており、ハードブート前にも実施されます。ログが保存されるディレクトリの所有者はルートであり、そのディレクトリにはすべての権限があります。

権限拒否エラーを引き起こす手がかりはありますか？

ベストアンサー1

元のエラーメッセージは実行中の項目に関連していますlogrotate。

rotating pattern: /home/mail3/log/popMailProcessing.log  forced from command line (60 rotations)
empty log files are rotated, old logs are removed
considering log /home//log/popMailProcessing.log
error: stat of /home/mail3/log/popMailProcessing.log failed: Permission denied

これらのルートは何をしますか/home/mail3/log/*？また、行方不明の行は何ですか/home//log/popMailProcessing.log？あなたの質問は実際の状況を示すようです。

デバッグの問題

次の行をシェルスクリプトに入れますlogrotate.sh。

#!/bin/bash
/usr/sbin/logrotate -f -v /etc/logrotate.d/mail3-logs &>> /var/log/logrotate/rotate.log

実行可能にし、cronで実行します。

03 00 * * * root strace -s 2000 -o /tmp/strace.log /path/to/logrotate.bash

出力を見ると、どの権限問題が問題を引き起こしているかを確認できます。

編集＃1

OPと会話した後、彼は上記のデバッグ技術によってSELinuxが有効になったことを発見したと述べました。彼は以前にコマンドで無効にしたので、なぜこれが起こるのか混乱しましたsetenforce 0。

この方法でSELinuxを無効にすると、次回再起動するまでそのまま残ります。 SELinuxのデフォルトモードは、Fedora / CentOSで次のファイルとして指定されます。

$ cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#   enforcing - SELinux security policy is enforced.
#   permissive - SELinux prints warnings instead of enforcing.
#   disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
#   targeted - Only targeted network daemons are protected.
#   strict - Full SELinux protection.
SELINUXTYPE=targeted

SELinuxを永久に無効にするには、この行を3つのSELINUX=..状態のいずれかに変更する必要があります。enforcingpermissivedisabled

ただし、時間がかかるため、SELinuxがこれらのログファイルを含むディレクトリへのアクセスを許可しない理由を理解し、SELinuxがこのアクセスを許可するように適切なコンテキストを追加することをお勧めします。 SELinuxは、それを使用するLinuxディストリビューションで推進される階層型セキュリティモデルの重要な部分であり、それを盲目的に無効にすると、重要な階層の1つが削除されます。

引用する

おすすめ記事