рм не освобождает дисковое пространство

Question

Я rm редактировал файл журнала размером 2,5 ГБ, но, похоже, он не освободил место.

Я сделал:

rm /opt/tomcat/logs/catalina.out

тогда это:

df -hT

и df сообщили, что мое /opt монтирование все еще используется на 100%.

Есть предложения?

Answer 1

Перезапустите tomcat, если файл используется и вы удалите его, место станет доступным после завершения этого процесса.

Answer 2

Как и предполагали другие, файл, вероятно, все еще открыт другими процессами. Чтобы узнать, по каким из них вы можете сделать

lsof /opt/tomcat/logs/catalina.out

, который перечисляет вам процессы. Возможно, вы найдете кота в этом списке.

Answer 3

Ваша проблема:

Возможно, что запущенная программа все еще удерживает файл.

Ваше решение:

Согласно другим ответам здесь, вы можете просто выключить tomcat, чтобы он не держался за файл.

Если это не вариант, или если вы просто хотите узнать больше, проверьте этот вопрос: Найдите и удалите большие файлы, которые открыты, но были удалены - он предлагает некоторые более жесткие способы борьбы с это может быть более полезным для вашей ситуации.

---

Подробнее:

Файловая система linux / unix считает "открытые" файлы другим именем для них. rm удаляет «имя» из файла, как видно из дерева каталогов. Пока дескрипторы не закрыты, файлы по-прежнему имеют больше «имен», и поэтому файл все еще существует. Файловая система не получает файлы до тех пор, пока они не будут полностью безымянными.

Это может показаться немного странным, но при таком подходе можно использовать такие полезные вещи, как включение символических ссылок. Символьные ссылки могут рассматриваться как альтернативное имя для того же файла.

Вот почему важно всегда называть ваши языки эквивалентными close () для дескриптора файла, если вы закончили с ним. Это уведомляет ОС о том, что файл больше не используется. Хотя иногда это не помогает - что, скорее всего, имеет место с Tomcat. Обратитесь к Ответу Билла Карвина , чтобы узнать почему.

В зависимости от файловой системы это обычно реализуется как своего рода подсчет ссылок, поэтому здесь не должно быть никаких реальных имен. Также может быть странно, если такие вещи, как stdin и stderr, перенаправляются в файл или другой поток данных (чаще всего это делается с помощью сервисов).

Вся эта идея тесно связана с понятием inode , поэтому, если вы любопытный тип, я бы рекомендовал сначала проверить это.

Обсуждение

Он больше не работает так хорошо, но вы имели обыкновение обновлять всю ОС, запускать новый http-демон с использованием новых библиотек и, наконец, закрывать старый, когда больше клиентов не обслуживается это (выпуская старые ручки). http-клиенты даже не пропустят ритм.

По сути, вы можете полностью уничтожить ядро ​​и все библиотеки "из-под" запущенных программ. Но так как «имя» все еще существует для более старых копий, файл все еще существует в памяти / диске для этой конкретной программы. Тогда это будет вопрос перезапуска всех сервисов и т. Д. Несмотря на то, что это сценарий расширенного использования, это причина, по которой некоторые системы Unix записывают годы безотказной работы.

Answer 4

Перезапуск Tomcat освободит все удержания, которые Tomcat имеет для файла. Однако, чтобы избежать перезапуска Tomcat (например, если это производственная среда, и вы не хотите без необходимости отключать службы), вы можете просто перезаписать файл:

cp /dev/null /opt/tomcat/logs/catalina.out

Или еще короче и прямее:

> /opt/tomcat/logs/catalina.out

Я все время использую эти методы для очистки файлов журнала для текущих запущенных серверных процессов в процессе устранения неполадок или очистки диска. Это оставляет инод в одиночку, но очищает фактические данные файла, тогда как попытка удаления файла часто либо не работает, либо, по крайней мере, сбивает с толку средство записи журнала запущенного процесса.

Answer 5

Как отметили в этом потоке FerranB и Пол Томблин, файл используется и дисковое пространство не будет освобождено до тех пор, пока файл не будет закрыт.

Проблема в том, что вы не можете сигнализировать процессу Catalina о закрытии catalina.out, потому что дескриптор файла не контролируется процессом Java. Он был открыт перенаправлением ввода / вывода в catalina.sh при запуске Tomcat. Только после завершения процесса Catalina этот дескриптор файла может быть закрыт.

Есть два решения, чтобы предотвратить это в будущем:

• Не разрешать вывод данных из приложений Tomcat в catalina.out. Вместо этого используйте свойство swallowOutput и настройте каналы журнала для вывода. Журналы, управляемые log4j, можно вращать без перезапуска процесса Catalina.

• Измените catalina.sh для вывода на канал cronolog вместо простого перенаправления на catalina.out. Таким образом cronolog будет вращать журналы для вас.

Answer 6

лучшее решение - использовать 'echo' (как совет @ejoncas):

$ echo '' > huge_file.log  

Эта операция довольно безопасна и быстра (удаляет около 1 ГБ данных в секунду), особенно если вы работаете на своем производственном сервере.

Не просто удаляйте этот файл с помощью 'rm', потому что сначала вам нужно остановить процесс его записи, иначе диск не будет освобожден.

см .: http://siwei.me/blog/posts/how-to-deal-with-huge-log-file-in-production

Answer 7

Если есть вторая жесткая ссылка на файл, он не будет удален, пока он не будет удален.

Answer 8

Если что-то все еще открыто, файл на самом деле не исчезнет. Возможно, вам нужно как-то подать сигнал каталине, чтобы закрыть и заново открыть ее файлы журналов.

Answer 9

Введите команду, чтобы проверить, какие удаленные файлы заняли память

 $ sudo lsof | grep deleted

Он покажет удаленный файл, который все еще содержит память.

Затем завершите процесс с помощью pid или имени

$ sudo kill <pid>
$ df -h

проверьте, теперь у вас будет такая же память

Если нет, введите команду ниже, чтобы увидеть, какой файл занимает память

# cd /
# du --threshold=(SIZE)

укажите любой размер, который покажет, какие файлы занимают размер выше порогового, и удалите файл

Answer 10

Журнал зарегистрирован / запланирован? Попробуйте команду sync для принудительной записи.