解決策 1:
適切な設計
問題のファイルシステムを単純に拡張することはできないと思います（ lvextend && ext2online を使用） )、LVM を使用していないか、間違ったファイルシステム タイプを使用しているためです。
あなたのアプローチ
あなたが提案したことはかもしれません SIGHUP (kill -1 pid) でデーモンにシグナルを送ると動作します。明らかに、後で「mount -o bind / /somewhere」を実行し、マウントされた /var/log の下に残っているものをクリーンアップする必要があります。しかし、特に本番環境では、私には悪臭がします.
ダウンタイムを回避し、クリーンな結果を得る (ただし、実行は複雑)
"mount -o bind" のアイデアは忘れて、新しい LV/パーティションを作成しますが、まだマウントしないでください。
lsof | grep /var/log # lists open files in /var/log
開いているファイルを持つ各デーモン (少なくとも syslog、inetd、sshd が必要です):
- /var/log にログを記録するようにデーモン no を再構成
- デーモンを更新します (
kill -1または/etc/init.d/script reload) lsof | grep /var/logで確認 そのデーモンはファイルを閉じました
/var/log にマウントします。古い構成を復元し、SIGHUP/デーモンを再度ロードします。
簡単な方法 (ダウンタイム)
新しい LV/パーティションを作成し、/var または /var/log に適切にマウントします。簡単な方法は、サーバーを停止してメンテナンス モード (シングル ユーザー モード) にし、操作に (ssh ではなく) 実際のコンソールを使用することです。
解決策 2:
他の皆さんの回答は素晴らしく、正しいので、必ず最初に読んでください。
あなたのケースが私のような非常に単純なものであることが判明した場合は、簡単にコピーして貼り付けることができるので、これを共有したいと思いました:
syslog を停止し、現在のログをコピーします:
service rsyslog stop
mkdir -p /tmp/varlog
cp -r /var/log/* /tmp/varlog
次に、新しい場所を /var/log にマウントします . /dev/sdb という新しいデバイスだとしましょう
mount /dev/sdb /var/log
これで、ファイルをコピーして syslog を再起動できます:
cp -r /tmp/varlog/* /var/log
rm -rf /tmp/varlog
service rsyslog start
このすべてがマシンの寿命のかなり早い段階で発生すると仮定すると、rsyslog 実行中の唯一のデーモンである可能性があります。 YMMV!
PS - fstab に追加したくなるでしょう。 同様におそらく。これを行う 1 つの方法を次に示します。ここでも、非常に単純なマウントを想定しています。
cat /etc/mtab |grep /var/log >>/etc/fstab
(mtab から fstab への cat については https://serverfault.com/a/267610/80606 を参照)
解決策 3:
他にできることは次のとおりです。
/var/logでファイルを開いているプロセスを停止する/var/logでファイルを開いているプロセスがないことを確認する (lsofを使用) クバンスカマックが提案したように）- あなたの
/var/logを動かしてください 十分な空き容量がある別のパーティションに (あなたの例に従うと、それは/home/logになります) ) - /var/log から /home/log へのシンボリック リンクを作成します (
ln -s /home/log /var/log) - 最初のステップで停止したプロセスを再開します
これは、私が良い習慣と考えるものとはかけ離れていることに注意してください。サーバーをシャットダウンする必要がないようにするための回避策です。正しい解決策は、新しい /var を作成することです または /var/log 十分なスペースのあるパーティション (または現在のパーティションを拡張)、