Linux-сервер не має місця

Мені було задано це питання у двох інтерв'ю поспіль, але після деяких досліджень та перевірок у різних системних адміністраторів я не отримав гарної відповіді. Мені цікаво, чи хтось може мені тут допомогти.

Сервер не має місця на диску. Ви помічаєте дуже великий файл журналу і визначаєте, що його безпечно видалити. Ви видаляєте файл, але на диску все одно видно, що він повний. Що б це спричинило і як би ви виправили це? І як би ви дізналися, який процес пише цей величезний файл журналу?

Це поширене запитання про інтерв'ю та ситуація, яка виникає в різних виробничих умовах.

Записи каталогу файлів видалено, але процес реєстрації все ще триває. Операційна система не поверне пробіл доти, доки всі ручки файлів не будуть закриті (наприклад, процес було вбито) та не буде видалено всі записи каталогів. Щоб знайти процес запису у файл, вам потрібно буде скористатися lsofкомандою.

Інша частина питання іноді може бути: "як очистити файл, до якого записується, не вбиваючи процес?" В ідеалі, ви б "нулю" або "обрізали" файл журналу чимось на зразок, : > /var/log/logfileа не видаляючи файл.

Є ще одне посилання на файл (або жорстке посилання, або ручка відкритого файлу). Видалення файла видаляє лише запис каталогу; дані файлу та inode зависають, поки не видалено останню посилання на нього.

Службою є дещо поширена практика створення тимчасового файлу та негайно його видалення, зберігаючи файл відкритим. Це створює файл на диску, але гарантує, що файл буде видалено, якщо процес закінчиться аномально, а також убереже від інших процесів від випадкового пошкодження файлу. MySQL робить це, наприклад, для всіх своїх тимчасових таблиць на диску. Зловмисне програмне забезпечення часто використовує подібну тактику, щоб приховати свої файли.

У Linux ви можете легко отримати доступ до цих видалених файлів як /proc/<pid>/fd/<filenumber>.

Я не sysadmin, але з того, що я зібрав на Unix.SE, система Linux насправді не видалить файл (позначте простір як вільний / багаторазовий використання) після його від’єднання, поки всі дескриптори файлів, які вказують на них, не матимуть було закрито. Отже, щоб відповісти на першу частину, простір ще не вільний, оскільки процес все ще його читає. Щоб відповісти на друге, ви можете побачити, для якого процесу використовується файл lsof.

Один варіант відповіді, окрім очевидного жорсткого посилання / відповіді на відкритий файл: цей файл є (дуже) розрідженим файлом, наприклад, /var/log/lastlogна RHEL, який насправді не займає все так багато місця. Видалення його мало дуже малий вплив, тому вам потрібно переглянути наступний найбільший файл.

Якщо процес написання файлу є кореневим, він запишеться в резервований простір файлів суперпользователя. У файловій системі є цей простір для збереження операційної системи у випадку, якщо завдання користувача заповнюють диск. Цей простір (imho на 5% за замовчуванням) є невидимим для багатьох інструментів.

lsof може показати вам, який процес заблокував файл, Ergo пише на нього.

Окрім того, що файл відкривається процесом, другий випадок - це коли у вас є файлова система, яка підтримує знімки типу btrfsабо ZFS.

Наприклад, ви робите знімок із наявним величезним файлом журналу. Якщо ви видалите файл зараз, ви видалите лише дельту. А дельта видаляється лише тоді, коли файл не використовується.

Дивись також:

• https://superuser.com/questions/863588/how-to-delete-a-file-in-all-snapshots-on-a-btrfs-system

• ZFS: Видалення файлів із знімків?

Третій випадок - це коли у вас є файлова система, яка підтримує дедуплікацію рівня блоку, і більша частина файлу ідентична іншому файлу. Я не очікую, що це станеться для журналу, якщо у вас немає контейнера або VM, який надсилає журнали до контейнера syslog або VM, які мають однаковий FS, щоб вміст журналу був ідентичним.