タグ付けされた質問 「rm」

29
偶発的なrm -rf / *を防ぐにはどうすればよいですか?
私はrm -rf /*偶然に走りましたが、意味しましたrm -rf ./*(スラッシュの後の星に注意してください)。 alias rm='rm -i'そして--preserve-rootデフォルトでは私を救わなかったので、これのための自動安全装置はありますか? 私はrootではなく、すぐにコマンドをキャンセルしましたが、Bashプロンプトがすでに壊れていることに気付いたので、どこかで何かリラックスした許可がありました。私は、権限に依存するとされていないルート(私は同じミスを犯す可能性が望んでいないsudo)、と私はので、システムのどこかにファイルがない1の神秘的なバグのために狩りをしたくないので、バックアップをしてsudo良いです、しかし、私はこの特定の場合により良いものが欲しいです。 二度考えて、脳を使うことについて。実際に使用しています!しかし、私はそれを使用して、10種類の複雑なプログラミングタスクを解決しています。私はこのタスクに深く没頭しています。フラグとパスをチェックするための脳力は残っていません。コマンドと引数についても考えていません。「空の現在のディレクトリ」などのアクションについても考えています。私の脳の異なる部分がそれらをコマンドに変換し、時には間違いを犯します。少なくとも危険なものは、コンピューターに修正してほしい。

23
数百万のファイルがあるディレクトリでのrm
背景:物理サーバー、約2年、3Ware RAIDカードに接続された7200-RPM SATAドライブ、ext3 FSマウントnoatimeおよびdata = ordered、狂気の負荷なし、カーネル2.6.18-92.1.22.el5、稼働時間545日。ディレクトリにはサブディレクトリが含まれておらず、数百万の小さなファイル(〜100バイト)と、いくつかの大きな(数KB)ファイルがあります。 過去数か月の間に少しカッコウしたサーバーがありますが、ファイルが多すぎるためにディレクトリに書き込めなくなったのは先日だけです。具体的には、/ var / log / messagesにこのエラーをスローし始めました。 ext3_dx_add_entry: Directory index full! 問題のディスクには、多くのiノードが残っています。 Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 60719104 3465660 57253444 6% / したがって、ディレクトリファイル自体に含めることができるエントリの数の制限に達することを意味していると思います。ファイルがいくつになるかはわかりませんが、ご覧のとおり、300万個以上になることはありません。それは良いことではありません、気に!しかし、それは私の質問の一部です:その上限は正確に何ですか?調整可能ですか?私が怒鳴る前に、私はそれを抑えたいです。この巨大なディレクトリはあらゆる種類の問題を引き起こしました。 とにかく、これらすべてのファイルを生成していたコードの問題を追跡し、修正しました。今、私はディレクトリを削除することにこだわっています。 ここにいくつかのオプションがあります: rm -rf (dir) 最初にこれを試しました。目立った影響なしに1日半走った後、私はそれをあきらめて殺した。 ディレクトリでのunlink(2):間違いなく検討に値しますが、質問はunlink(2)で削除するよりもfsckでディレクトリ内のファイルを削除する方が速いかどうかです。つまり、何らかの方法で、これらのiノードを未使用としてマークする必要があります。もちろん、これはfsckに/ lost + found内のファイルにエントリをドロップしないように指示できることを前提としています。そうでなければ、私は問題を動かしただけです。他のすべての懸念に加えて、これについてもう少し読んだ後、おそらく私が見つけることができるunlink(2)バリアントのどれも私がただ単に削除することを許可しないため、いくつかの内部FS関数を呼び出さなければならないでしょうエントリが含まれるディレクトリ。プー。 while [ true ]; do ls -Uf | head …
104 kernel  ext3  rm  directory 

5
`rm -rf / --no-preserve-root`はBIOSを台無しにできますか?
システム全体をtarballし、それがfoobar'dであった場合にそのシステムを復元するおおよその速度を確認するために、私たちの会社のシステムに不可欠ではないが、機能している。システム全体のtarballを作成する時間を計り、それを調べて見た目が良いことを確認しました。 それから走りましたrm -rf / --no-preserve-root。それをする機会がなかったので、とても楽しかったです。最初は。 ボックスを再起動すると、何も表示されませんでした。「Dell」ロゴではなく、BIOSのオプションでもありません。 ドライブを別のボックスに接続すると、残念なことにUEFIパーティションがあることがわかりました。私の死の司令部はそのパーティションを効果的に使い果たしたと思います。 現在機能していないワークステーションに別の機能するドライブを接続しましたが、ワークステーションはまだ何もしません。 誰かがこのようなものを見ましたか、何を探すべきかについての提案がありますか?そのrmコマンドを実行すると、ボックス全体がどのように高貴に台無しになったのでしょうか? 更新:箱をデルに返却しました。それが偶然なのか、dronusが述べているような状況なのかを正確に診断することはできませんでした。ただし、これが発生する可能性のある理由を説明しているドロヌスの回答を受け入れます。さらに、将来同じことをしないように他の人に警告します。誰かがバグのあるUEFIを使用してDellの記録を見つけたら、それは役に立ちます。
35 bios  rm  uefi 

11
ext3 / linuxで `rm`を高速化するには?
デフォルトのオプションでマウントされたext3ファイルシステムがあります。その上にいくつかの〜100GBのファイルがあります。 そのようなファイルを削除すると、長時間(8分)かかり、大量のIOトラフィックが発生し、サーバーの負荷が増加します。 rmをそれほど混乱させない方法はありますか?
32 linux  performance  ext3  rm  unlink 

2
Ansibleはシェルスクリプトで 'rm -rf /'の実行を防止します
これは、このデマの質問に基づいています。説明されている問題は、次の効果をもたらすものを含むbashスクリプトを持っていることです。 rm -rf {pattern1}/{pattern2} ...両方のパターンに1つ以上の空の要素が含まれる場合rm -rf /、元のコマンドが正しく転写され、OPがパラメーター展開ではなくブレース展開を行っていると仮定して、少なくとも1つのインスタンスに展開されます。 OPによるデマの説明では、彼は次のように述べています。 コマンド[...]は無害ですが、ほとんど誰も気付いていないようです。 Ansibleツールはこれらのエラーを防止しますが[...]しかし[...]誰もそれを知らないようでした。さもなければ彼らは私が説明したことが起こらないことを知っているでしょう。 したがってrm -rf /、ブレース展開またはパラメーター展開のいずれかを介してコマンドを発行するシェルスクリプトがあると仮定すると、Ansibleを使用するとそのコマンドの実行が妨げられるというのは本当ですか? rm -rf /あなたがそれを行うためにAnsibleを使用している限り、root権限で実行することは本当に「無害」ですか?
23 linux  bash  ansible  rm 



3
サブツリーの削除( `rm -rf`)がディスクI / Oのための他のプロセスを枯渇させないようにする方法は?
ビジーなサイト用に非常に大きな(マルチGB)Nginxキャッシュディレクトリがあり、一度にすべてをクリアする必要がある場合があります。キャッシュフォルダーを新しいパスに移動し、古いパスに新しいキャッシュフォルダーを作成しrm -rf、古いキャッシュフォルダーを使用することで、これを以前に解決しました。 しかし、最近、忙しい朝にキャッシュをクリアする必要がある場合rm -rf、Nginxとその前にあるサーバーの両方が読み取り集中型であるため、I / O がサーバーアクセスのディスクアクセスを枯渇させています。CPUがアイドル状態にありrm -rf、ディスクIOの98〜99%を占める間に、負荷平均の上昇を観察できiotopます。 をionice -c 3呼び出すときに試しましたrmが、観測された動作にそれほど影響はないようです。 rm -rfさらにディスクを共有するために飼いならす方法はありますか?手がかりを得る別のテクニックを使用する必要がありioniceますか? 更新: 問題のファイルシステムはAWS EC2インスタンスストアです(プライマリディスクはEBSです)。/etc/fstabエントリは次のようになります。 /dev/xvdb /mnt auto defaults,nobootwait,comment=cloudconfig 0 2
8 linux  hard-drive  io  rm  ionice 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.