/ tmpを別のボリュームに（安全に）移動する方法は？
今日、/tmpディレクトリは、職場のマシンでいっぱいになりました。問題は、それほど大きくないルートパーティション上にあったということです。これを修正するために、同僚は/new/tmpディレクトリを別の場所に作成し、すべてのコンテンツを新しいディレクトリにコピーして、元の/tmpを削除し、シンボリックリンク/tmp -> /new/tmpを作成しました。
彼がファイルをコピーしたとき（実際には、これは私ではなく他の誰かでした！）、-aを使用しなかったため、/new/tmpの下のすべてのファイルの所有者はrootでした。さらに、彼は/new/tmpディレクトリのアクセス許可を設定しなかったため、これがデフォルトの0755でした。これにより問題が発生することはなく、微調整モードと所有権ビットでさえ、マシンを許容できる動作状態に復元できませんでした。 /tmpのすべてを核にして再起動する必要がありました。
/tmpディレクトリには、さまざまなソケットやパイプなどが含まれています。多くの人々がVNCを介してGnomeを実行しているため、独自のパイプを持つscreenを使用しています。
実行中のシステムの別のボリュームに/tmpディレクトリを移動するsafe方法はありますか？すべてを機能させるために実際に何をしたかわかりません。パイプとソケットに何が起こるかについて、私は特に興味があります。
「クライアント」マシンでは、/tmpを移動する安全な方法は再起動することです。ここで、クライアントとは、ソケットを/tmpに配置するプログラムを実行するもの、特にXサーバーと画面を意味します。
新しい/tmpには間違いなく適切な権限（1777）が必要です。そうでないと、システムが機能することを期待できません。
/tmpの場合、ファイルをコピーすることはほとんどできません。これは、ほとんどの場合、/tmpにデータを入れるプログラムがファイルを開くためです。ファイルをコピーすると、コンテンツがコピーされますが、プログラムは古いファイルを開いたままにします。デバッガ（ptrace）を使用してそれらにアクセスできる場合がありますが、これは再起動よりもはるかに複雑であり、多くのプログラムでは、とにかくそれらをクラッシュさせるだけです。
/tmpがいっぱいで、新しいライブに切り替える場合は、ファイルが開いているすべてのプログラムを再起動する必要があります。これはXセッションとスクリーンセッションを再起動することを意味するため、再起動よりもはるかに優れています。
union mount を使用して、新しいプログラムに切り替えることができるが、既存の開いているファイルをそのままにしておくことができます。 （原則は健全ですが、私は試したことがないため、予期しない問題が発生する可能性があります。）Linuxでこれを行う方法は次のとおりです。
- 手動で選択したいくつかの大きなファイルを除いて、すべての既存のファイルを
/tmpに保持します。 /tmp.new（モード1777）を作成します。- 別のパスで
/tmpを公開します：mount --bind / /.root.only。次のステップは/tmpをシャドウするため、これは必要です。この手順を必要としない別のユニオンマウント実装がある場合があります。 /.root.only/tmpにマウントされた/tmp.newと/tmpのユニオンマウントを作成します。このようにして、/tmpで作成された新しいファイルは/tmp.newに書き込まれますが、/.root.only/tmpのファイルも/tmpの下に表示されます。 1つの可能性は nionfs-Fuse ：unionfs-Fuse /tmp.new:/.root.only/tmp /tmpです。
ユニオンマウントルートに移動したくない場合（たとえば、プラットフォームで使用できないため、または問題が多すぎるため）、少なくとも古いディレクトリを削除しないでください。 Moveこれにより、実行中のプログラムは古いディレクトリを使用し続け、新しいプログラムは新しいディレクトリを使用します。 （もちろん、新しいプログラムは、TMPDIRを設定するか、どこに検索するかを指定しない限り、/tmpのソケットまたはパイプを介して古いプログラムと通信することはできません。）
mv /tmp /tmp.old && mkdir /tmp