Telegram Group & Telegram Channel
🐧 Задача с подвохом: Странное поведение с `df` и `du`

Условие:

Вы замечаете, что на сервере /var/log неожиданно «занялось» много места. Проверяете это так:


df -h /var


И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в /var/log:


du -sh /var/log


— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает df.

Вопрос:
Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?

🔍 Подсказка:

На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён logrotate, старые логи удалились.

---

Разбор:

💥 Подвох:

Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.

Вот что происходит:

-
du показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены).
-
df показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами.

🚩 Это классическая ситуация после
logrotate: старые логи удаляются, но процессы, которые их писали (например, nginx, `mysql`), продолжают держать дескрипторы открытыми.

🔧 Как найти виновника:

Используем
lsof для поиска удалённых, но ещё открытых файлов:

```bash
lsof | grep deleted
```

Вы увидите что-то вроде:

```
nginx 1234 ... /var/log/nginx/access.log (deleted)
```

🛠 Как исправить без перезагрузки:

1️⃣ Перезапустить приложение, которое держит файл открытым:

```bash
systemctl restart nginx
```

2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда).

---

Вывод:

df и du показывают разное, потому что считают разными методами:
-
df: что реально занято на диске (включая удалённые, но ещё открытые файлы)
-
du: что физически доступно через файловую систему

• Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps!

💡 Бонус-вопрос для гуру:
Что произойдёт, если в
lsof вы видите удалённый файл, но процесс — это docker? Как поступить в этом случае? 😉



tg-me.com/DevOPSitsec/1483
Create:
Last Update:

🐧 Задача с подвохом: Странное поведение с `df` и `du`

Условие:

Вы замечаете, что на сервере /var/log неожиданно «занялось» много места. Проверяете это так:


df -h /var


И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в /var/log:


du -sh /var/log


— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает df.

Вопрос:
Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?

🔍 Подсказка:

На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён logrotate, старые логи удалились.

---

Разбор:

💥 Подвох:

Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.

Вот что происходит:

-
du показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены).
-
df показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами.

🚩 Это классическая ситуация после
logrotate: старые логи удаляются, но процессы, которые их писали (например, nginx, `mysql`), продолжают держать дескрипторы открытыми.

🔧 Как найти виновника:

Используем
lsof для поиска удалённых, но ещё открытых файлов:

```bash
lsof | grep deleted
```

Вы увидите что-то вроде:

```
nginx 1234 ... /var/log/nginx/access.log (deleted)
```

🛠 Как исправить без перезагрузки:

1️⃣ Перезапустить приложение, которое держит файл открытым:

```bash
systemctl restart nginx
```

2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда).

---

Вывод:

df и du показывают разное, потому что считают разными методами:
-
df: что реально занято на диске (включая удалённые, но ещё открытые файлы)
-
du: что физически доступно через файловую систему

• Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps!

💡 Бонус-вопрос для гуру:
Что произойдёт, если в
lsof вы видите удалённый файл, но процесс — это docker? Как поступить в этом случае? 😉

BY DevOps


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/DevOPSitsec/1483

View MORE
Open in Telegram


DevOps Telegram | DID YOU KNOW?

Date: |

A Telegram spokesman declined to comment on the bond issue or the amount of the debt the company has due. The spokesman said Telegram’s equipment and bandwidth costs are growing because it has consistently posted more than 40% year-to-year growth in users.

DevOps from it


Telegram DevOps
FROM USA