🐧Задача с подвохом: Странное поведение с `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
Most people buy Bitcoin via exchanges, such as Coinbase. Exchanges allow you to buy, sell and hold cryptocurrency, and setting up an account is similar to opening a brokerage account—you’ll need to verify your identity and provide some kind of funding source, such as a bank account or debit card. Major exchanges include Coinbase, Kraken, and Gemini. You can also buy Bitcoin at a broker like Robinhood. Regardless of where you buy your Bitcoin, you’ll need a digital wallet in which to store it. This might be what’s called a hot wallet or a cold wallet. A hot wallet (also called an online wallet) is stored by an exchange or a provider in the cloud. Providers of online wallets include Exodus, Electrum and Mycelium. A cold wallet (or mobile wallet) is an offline device used to store Bitcoin and is not connected to the Internet. Some mobile wallet options include Trezor and Ledger.
The lead from Wall Street offers little clarity as the major averages opened lower on Friday and then bounced back and forth across the unchanged line, finally finishing mixed and little changed.The Dow added 33.18 points or 0.10 percent to finish at 34,798.00, while the NASDAQ eased 4.54 points or 0.03 percent to close at 15,047.70 and the S&P 500 rose 6.50 points or 0.15 percent to end at 4,455.48. For the week, the Dow rose 0.6 percent, the NASDAQ added 0.1 percent and the S&P gained 0.5 percent.The lackluster performance on Wall Street came on uncertainty about the outlook for the markets following recent volatility.
