/ tmpディレクトリ：0ファイルですが、完全に表示されますか？
別の投稿者のおかげで、/ tmp内のファイルを最終的に削除できた別の投稿に関連しています。
ただし、最終的に、システム管理者はmysqlサービスをバックアップするために数日前のスナップショットを復元する必要がありました。
私は、mysqlサーバーが実行されていないと推測しました。 1つのエラーは、mysqld.sock/.pidファイルを作成するためにtmp dirに書き込めなかったため、それらが存在しなかったことです。
したがって、サーバーは再起動/再起動され、最終的に以前のスナップショットから復元されたため、すべてが現在動作していますが、そのスナップショットは数日前のものであったため、tell-tellサインはこの出力にあります：
drwxrwxrwt 2 root root 34471936 Oct 8 20:47 tmp
その大きな数はまだ何とか「記憶」されており、そのフォルダに何が書き込まれているのかを調べようとしていますか？ Drupalでは、プレビューファイルのパスはそのディレクトリに設定されていますが、ダウンロードやプレビューなどの一連のテストを行いました（サイトにはログインアカウントがありません/データのためだけです）そのフォルダへの書き込みですか？
これは、何らかの問題がない限り、シャットダウン/リブートされないWebサーバーです。それでも、/ tmpディレクトリは再起動時に空になりません。また、rsCファイルでは、TMPTIME=0はデフォルトのままです。
それで、実際のディレクトリが空のときに、その3441936サイズを維持しているものを他にどこで調べるべきか、またはどのように調査するのかわかりません。または、そのディレクトリを使用しているプロセスを検索する方法。
これは、Drupalインストール用です。 Ubuntu 12。
これを試して。
$ Sudo lsof | egrep '^COMMAND|deleted'
システムに表示される出力例...
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mysqld 2842 mysql 5u REG 9,1 4633 6209543 /tmp/ibLRNV1i (deleted)
mysqld 2842 mysql 6u REG 9,1 424 6209545 /tmp/ibnnYl1y (deleted)
mysqld 2842 mysql 7u REG 9,1 0 6209546 /tmp/ib5ViM0O (deleted)
mysqld 2842 mysql 8u REG 9,1 0 6209547 /tmp/ibh9U55F (deleted)
mysqld 2842 mysql 13u REG 9,1 0 6209548 /tmp/ibRzqtwm (deleted)
mysqld 2842 mysql 319u REG 9,1 25894907 6209553 /tmp/MLFxqPDX (deleted)
mysqld 2842 mysql 350u REG 9,1 267677827 6209550 /tmp/MLFBkHbP (deleted)
多くの* nixファイルシステムに共通する特徴は、削除されたファイルに対するプロセスの読み取り/書き込みの継続を妨げるものは何もないこと、およびプロセスがまだ開いているファイルの削除を妨げるものは何もないという事実です。
一部のプログラムでは、一時ファイルが保持されないことを保証します（これはセキュリティ対策としても可能ですが、これがどの程度「安全」かはわかりません）、それらを開いてすぐに「リンク解除」（削除）します。プロセスが予期せず終了した場合、ディスク領域は解放されます。 MySQLはこれを行います：
MySQLは、mysqldが終了すると一時ファイルが削除されるように調整します。サポートしているプラットフォーム（Unixなど）では、ファイルを開いた後にファイルのリンクを解除することでこれを行います。これの欠点は、名前がディレクトリリストに表示されず、一時ファイルディレクトリが配置されているファイルシステムをいっぱいにする大きな一時ファイルが表示されないことです。 （そのような場合、lsof + L1はmysqldに関連付けられた大きなファイルを識別するのに役立つ場合があります。）
— http://dev.mysql.com/doc/refman/5.6/en/temporary-files.html
重要なポイント：まだ開いているファイルが削除されると、ファイルのハンドルを保持する最後のプロセスまでディスク上のスペースは実際には解放されません閉じます。ファイルが閉じられるまで、rootを含む誰もプロセスを強制終了しない限りそのスペースを解放できません。逆に、プロセスを強制終了（または、可能であれば正常に停止）すると、常にスペースが解放されます。
そのため、ファイルを開いたり削除したりする方法でシステムにどのような影響があるかを確認することをお勧めします。
私のシステムの場合、MySQLはいくつかの一時ファイルを開いていますが、それらのいくつかはかなり大きくなっています。
これらのファイルの内部を覗き込みたい場合は簡単に行えますが、識別できる内容は大きく異なります。これを行うPIDとFDの下の数字を取得します...例、PID 2842 FD 350
$ Sudo strings /proc/2842/fd/350 | less
MySQLが開いている一時ファイルを削除している場合、MySQLを停止して再起動するとそのスペースが解放され、それらが開いたままになっている可能性があるものを調査する必要があります。一時テーブルと/ tmpスペースを使い果たします。/tmpディレクトリが独自のパーティション/ファイルシステムである場合、df -hは空き領域と使用領域に関するより良い答えを提供します。おそらく、ディレクトリエントリ自体の実際のサイズについてあまり心配する必要はありません。
そしてもちろん、MySQLではないかもしれません。 :)
ファイルを削除しても、ext [234]はディレクトリのサイズを縮小しません。後で再利用できるように、エントリを削除済みとしてマークするだけです。これらの34 MBを再利用する場合は、ディレクトリを削除して再作成するか、レスキューモードで起動してボリュームでe2fsck -Dを実行する必要があります。