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 -
🐧Задача с подвохом: Странное поведение с `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
Like a stock, you can buy and hold Bitcoin as an investment. You can even now do so in special retirement accounts called Bitcoin IRAs. No matter where you choose to hold your Bitcoin, people’s philosophies on how to invest it vary: Some buy and hold long term, some buy and aim to sell after a price rally, and others bet on its price decreasing. Bitcoin’s price over time has experienced big price swings, going as low as $5,165 and as high as $28,990 in 2020 alone. “I think in some places, people might be using Bitcoin to pay for things, but the truth is that it’s an asset that looks like it’s going to be increasing in value relatively quickly for some time,” Marquez says. “So why would you sell something that’s going to be worth so much more next year than it is today? The majority of people that hold it are long-term investors.”
How To Find Channels On Telegram?
There are multiple ways you can search for Telegram channels. One of the methods is really logical and you should all know it by now. We’re talking about using Telegram’s native search option. Make sure to download Telegram from the official website or update it to the latest version, using this link. Once you’ve installed Telegram, you can simply open the app and use the search bar. Tap on the magnifier icon and search for a channel that might interest you (e.g. Marvel comics). Even though this is the easiest method for searching Telegram channels, it isn’t the best one. This method is limited because it shows you only a couple of results per search.
