Warning: mkdir(): No space left on device in /var/www/tg-me/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/DevOPSitsec/--): Failed to open stream: No such file or directory in /var/www/tg-me/post.php on line 50
DevOps | Telegram Webview: DevOPSitsec/1483 -
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: |

Launched in 2013, Telegram allows users to broadcast messages to a following via “channels”, or create public and private groups that are simple for others to access. Users can also send and receive large data files, including text and zip files, directly via the app.The platform said it has more than 500m active users, and topped 1bn downloads in August, according to data from SensorTower.

What is Telegram?

Telegram is a cloud-based instant messaging service that has been making rounds as a popular option for those who wish to keep their messages secure. Telegram boasts a collection of different features, but it’s best known for its ability to secure messages and media by encrypting them during transit; this prevents third-parties from snooping on messages easily. Let’s take a look at what Telegram can do and why you might want to use it.

DevOps from nl


Telegram DevOps
FROM USA