このようなケースは、一般的なタイトル「Working with error messages」の下の一連の小さな記事に値すると判断しました。
そして今日、私たちはみんなのお気に入りのgitプログラムからの贈り物を持っています。
もう一度、テストサーバーでgit pullを実行すると、クライアントは次のメッセージを確認しました。
致命的：「stdout」での書き込みエラー：デバイスにスペースが残っていません
そして、彼はなぜ彼が標準出力に書き込めなかったのかを理解するように頼みました
ディスク容量と空きiノードで十分でした。 同じリポジトリを別のディレクトリの同じサーバーに複製しても問題はありませんでした。
このフレーズをグーグルで検索しても何も起こりませんでした。
クローンが永続的であるという事実から、テストサーバーのローカルコピーが破損しているという結論に至ります。 gitリポジトリを修正するツールの検索を開始しましたが、奇妙なことに気付きました。
df -h Filesystem Size Used Avail Use% Mounted on /dev/simfs 535G 364G 144G 72% / none 2.9G 2.9G 0 100% /dev none 583M 1.1M 582M 1% /run none 5.0M 0 5.0M 0% /run/lock none 1.2G 0 1.2G 0% /run/shm none 100M 0 100M 0% /run/user
/ devセクションは、スペースの100％を占有します。 2.9Gはすべて奇妙です。
/ devに移動し、 ファイル / dev / nullを確認します 。そのサイズは、これらの2.9ギガバイトのサイズとまったく同じです。
どうやら、誰かがデバイス / dev / nullを削除すると、サービスは/ dev / nullへの書き込みを続け、通常のファイルを作成し、ゆっくりと場所を詰まらせました。
彼らはファイルを削除し、デバイスを作成し、/ dev / nullで書かれたサービスを再起動しました-/ devの空き領域が解放され、git pullは問題なくエラーなく動作しました。