🐧Задача с подвохом: Странное поведение с `df` и `du`
Условие:
Вы замечаете, что на сервере /var/log неожиданно «занялось» много места. Проверяете это так:
df -h /var
И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в /var/log:
du -sh /var/log
— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает df.
❓Вопрос: Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?
🔍Подсказка:
На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён logrotate, старые логи удалились.
---
✅Разбор: 💥Подвох:
Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.
Вот что происходит:
- du показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены). - df показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами.
🚩 Это классическая ситуация после logrotate: старые логи удаляются, но процессы, которые их писали (например, nginx, `mysql`), продолжают держать дескрипторы открытыми.
🔧Как найти виновника:
Используем lsof для поиска удалённых, но ещё открытых файлов:
1️⃣ Перезапустить приложение, которое держит файл открытым:
```bash systemctl restart nginx ```
2️⃣ Если нельзя перезапустить, можно попробовать «сбросить» файл, подменив его на новый (подходит не всегда).
---
✅Вывод:
• df и du показывают разное, потому что считают разными методами: - df: что реально занято на диске (включая удалённые, но ещё открытые файлы) - du: что физически доступно через файловую систему
• Если место не освобождается после удаления файла — ищите открытые файловые дескрипторы удалённых файлов. Это классика для DevOps!
💡Бонус-вопрос для гуру: Что произойдёт, если в lsof вы видите удалённый файл, но процесс — это docker? Как поступить в этом случае? 😉
🐧Задача с подвохом: Странное поведение с `df` и `du`
Условие:
Вы замечаете, что на сервере /var/log неожиданно «занялось» много места. Проверяете это так:
df -h /var
И видите, что диск почти полностью заполнен. Но при этом, когда проверяете размер файлов в /var/log:
du -sh /var/log
— оказывается, что размер логов совсем небольшой, явно не соответствующий тому, что показывает df.
❓Вопрос: Почему возникает такая ситуация? Что именно занимает место, если файлы почти пустые? Как это исправить, не перезагружая сервер?
🔍Подсказка:
На сервере активно работают несколько приложений, которые записывают логи. Недавно был произведён logrotate, старые логи удалились.
---
✅Разбор: 💥Подвох:
Многие думают, что после удаления файла место сразу освобождается. Но в Linux есть важный нюанс: если процесс всё ещё держит файл открытым, даже после удаления файла из файловой системы, его содержимое продолжает занимать место на диске.
Вот что происходит:
- du показывает размер существующих файлов, поэтому он маленький (ведь файлы удалены). - df показывает реальное использование блочного устройства, и оно включает те данные, которые всё ещё заняты удалёнными, но открытыми файлами.
🚩 Это классическая ситуация после logrotate: старые логи удаляются, но процессы, которые их писали (например, nginx, `mysql`), продолжают держать дескрипторы открытыми.
🔧Как найти виновника:
Используем lsof для поиска удалённых, но ещё открытых файлов:
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
That strategy is the acquisition of a value-priced company by a growth company. Using the growth company's higher-priced stock for the acquisition can produce outsized revenue and earnings growth. Even better is the use of cash, particularly in a growth period when financial aggressiveness is accepted and even positively viewed.he key public rationale behind this strategy is synergy - the 1+1=3 view. In many cases, synergy does occur and is valuable. However, in other cases, particularly as the strategy gains popularity, it doesn't. Joining two different organizations, workforces and cultures is a challenge. Simply putting two separate organizations together necessarily creates disruptions and conflicts that can undermine both operations.
Telegram auto-delete message, expiring invites, and more
elegram is updating its messaging app with options for auto-deleting messages, expiring invite links, and new unlimited groups, the company shared in a blog post. Much like Signal, Telegram received a burst of new users in the confusion over WhatsApp’s privacy policy and now the company is adopting features that were already part of its competitors’ apps, features which offer more security and privacy. Auto-deleting messages were already possible in Telegram’s encrypted Secret Chats, but this new update for iOS and Android adds the option to make messages disappear in any kind of chat. Auto-delete can be enabled inside of chats, and set to delete either 24 hours or seven days after messages are sent. Auto-delete won’t remove every message though; if a message was sent before the feature was turned on, it’ll stick around. Telegram’s competitors have had similar features: WhatsApp introduced a feature in 2020 and Signal has had disappearing messages since at least 2016.
