Rsyslogが正しく機能しておらず、何も記録していません
私はDebianサーバーを実行しています。数日前に、rsyslogが非常に奇妙に動作し始めました。デーモンは実行していますが、何も実行していないようです。多くの人がシステムを使用していますが、（合法的な）rootアクセス権を持つのは私だけです。
私はデフォルトのrsyslogd構成を使用しています（関連があると思われる場合は添付しますが、パッケージに付属しているものです）。
すべてのログファイルをローテーションした後、それらは空のままです。
# ls -l /var/log/*.log
-rw-r--r-- 1 root root 0 Jun 27 00:25 /var/log/alternatives.log
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/auth.log
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/daemon.log
-rw-r--r-- 1 root root 0 Jun 27 00:25 /var/log/dpkg.log
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/kern.log
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/lpr.log
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/mail.log
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/user.log
ログの書き込みを強制しようとしても効果はありません。
# logger hey
# ls -l /var/log/messages
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/messages
Lsofは、rsyslogdでログファイルが開かれていないことを示しています。
# lsof -p 1855
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rsyslogd 1855 root cwd DIR 202,0 4096 2 /
rsyslogd 1855 root rtd DIR 202,0 4096 2 /
rsyslogd 1855 root txt REG 202,0 342076 21649 /usr/sbin/rsyslogd
rsyslogd 1855 root mem REG 202,0 38556 32153 /lib/i386-linux-gnu/i686/cmov/libnss_nis-2.13.so
rsyslogd 1855 root mem REG 202,0 79728 32165 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so
rsyslogd 1855 root mem REG 202,0 26456 32163 /lib/i386-linux-gnu/i686/cmov/libnss_compat-2.13.so
rsyslogd 1855 root mem REG 202,0 297500 1061058 /usr/lib/rsyslog/imuxsock.so
rsyslogd 1855 root mem REG 202,0 42628 32170 /lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so
rsyslogd 1855 root mem REG 202,0 22784 1061106 /usr/lib/rsyslog/imklog.so
rsyslogd 1855 root mem REG 202,0 1401000 32169 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
rsyslogd 1855 root mem REG 202,0 30684 32175 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so
rsyslogd 1855 root mem REG 202,0 9844 32157 /lib/i386-linux-gnu/i686/cmov/libdl-2.13.so
rsyslogd 1855 root mem REG 202,0 117009 32154 /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
rsyslogd 1855 root mem REG 202,0 79980 17746 /usr/lib/libz.so.1.2.3.4
rsyslogd 1855 root mem REG 202,0 18836 1061094 /usr/lib/rsyslog/lmnet.so
rsyslogd 1855 root mem REG 202,0 117960 31845 /lib/i386-linux-gnu/ld-2.13.so
rsyslogd 1855 root 0u unix 0xebe8e800 0t0 640 /dev/log
rsyslogd 1855 root 3u FIFO 0,5 0t0 2474 /dev/xconsole
rsyslogd 1855 root 4u unix 0xebe8e400 0t0 645 /var/spool/postfix/dev/log
rsyslogd 1855 root 5r REG 0,3 0 4026532176 /proc/kmsg
私はイライラしてrsyslogパッケージを再インストールすることさえしましたが、それでも何もログに記録することを拒否します：
# apt-get remove --purge rsyslog
# apt-get install rsyslog
誰かがシステムをハッキングしたのではないかと思ったので、rkhunter、chkrootkit、unhideを実行して、リモートホストで非表示のプロセス/ポートとnmapを見つけ、netstatで示されたポートと比較します。これは何の意味もないことはわかっていますが、すべて問題ありません。システムには、着信/発信接続を非常に制限するiptablesファイアウォールもあります。
これは私を狂わせています、ここで何が起こっているのでしょうか？
[編集-ディスク容量情報]
# df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 24G 22G 629M 98% /
/dev/root 24G 22G 629M 98% /
devtmpfs 10M 112K 9.9M 2% /dev
tmpfs 76M 48K 76M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 151M 40K 151M 1% /tmp
tmpfs 151M 0 151M 0% /run/shm
[EDIT-strace info]
Straceは私にとっては大丈夫に見えます
[pid 28824] access("/var/log/auth.log", F_OK) = 0
[pid 28824] access("/var/log/syslog", F_OK) = 0
[pid 28824] access("/var/log/daemon.log", F_OK) = 0
[pid 28824] access("/var/log/kern.log", F_OK) = 0
[pid 28824] access("/var/log/lpr.log", F_OK) = 0
[pid 28824] access("/var/log/mail.log", F_OK) = 0
[pid 28824] access("/var/log/user.log", F_OK) = 0
[pid 28824] access("/var/log/mail.info", F_OK) = 0
[pid 28824] access("/var/log/mail.warn", F_OK) = 0
[pid 28824] access("/var/log/mail.err", F_OK) = 0
[pid 28824] access("/var/log/news/news.crit", F_OK) = 0
[pid 28824] access("/var/log/news/news.err", F_OK) = 0
[pid 28824] access("/var/log/news/news.notice", F_OK) = 0
[pid 28824] access("/var/log/debug", F_OK) = 0
[pid 28824] access("/var/log/messages", F_OK) = 0
完全なstraceログは here からダウンロードできます。
おそらくそれはファイルの所有権の問題です。 rsyslogはrootとして実行を開始しますが、次に特権をドロップし、ユーザーsyslogとして実行します（構成ディレクティブ $ PrivDropToUser ）。
syslogファイル（auth.log、daemon.logなど）は、最初はsyslog：admが所有していますが、所有権をrootに変更すると（ファイルリストにあるように）、rsyslogをHUP（リロード）するかどうかに関係なく再起動してください。特権がないため、これらのファイルを開くことが拒否されます。
ログのローテーション後に所有権の変更が発生した場合は、logrotate構成のcreateオプションを確認してください。 create 0644 syslog admの/etc/logrotate.d/rsyslogのように構成するか、さらに良い方法として、/etc/logrotate.confでグローバルに定義し、モード、所有者、グループを省略して、このcreateのように（デフォルト）ちなみに設定）。この場合、ファイルの同じ値が使用されます。詳細については、man logrotateをご覧ください。
Rsyslogの一部のバージョンには、ファイル所有権の外部変更の回避策としてディレクティブ $ omfileForceChown が含まれていますが、これはお勧めできません。推奨される方法は、所有権と権限を適切に構成することです。この問題の詳細については、このリンクを参照してください。
ファイルのアクセス許可がすべて適切で、logrotateが正しく構成されている場合、次のステップは、rsyslogシステムコールを確認することです。
# find the start command
me@d2-slprod02:~$ Sudo systemctl status rsyslog
● rsyslog.service - System Logging Service
Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-06-21 10:04:43 CEST; 2h 26min ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 18753 (rsyslogd)
Tasks: 4
Memory: 1.4M
CPU: 291ms
CGroup: /system.slice/rsyslog.service
└─18753 /usr/sbin/rsyslogd -n
# let's have a look at syscalls.
Sudo strace /usr/sbin/rsyslogd -n
...
write(2, "rsyslogd: error during parsing f"..., 206rsyslogd: error during parsing file /etc/rsyslog.d/50-default.conf, on or before line 8: warnings occured in file '/etc/rsyslog.d/50-default.conf' around line 8 [v8.16.0 try http://www.rsyslog.com/e/2207 ]
...
私のタイプミスがこのファイルで修正されるとすぐに/etc/rsyslog.d/50-default.conf、syslogが/ var/log/syslogへの書き込みを再開しました！
/ var/logがSSDの摩耗を減らすためにramdiskに常駐していて、それをHDDに移動したかったので、この問題がありました。
面白いのは、それがramdiskだったので、シングルユーザーモードでコピーするものがないので、アクセス許可と所有権がどうあるべきかがわからなかったのです。ああ。
新しい場所での短編小説：
chmod 770 /var/log
chgrp syslog /var/log
initctl restart rsyslog
Rsyslogは「syslog」ユーザー、グループ「syslog」として実行されるため、/ var/logに書き込むことができるようになります。