У меня есть rm
'файл журнала 2.5gb, но он, казалось, не освободил место.
Я сделал:
rm /opt/tomcat/logs/catalina.out
то это:
df -hT
и df
сообщили, что мое монтирование /opt
все еще используется на 100%.
Любые предложения?
У меня есть rm
'файл журнала 2.5gb, но он, казалось, не освободил место.
Я сделал:
rm /opt/tomcat/logs/catalina.out
то это:
df -hT
и df
сообщили, что мое монтирование /opt
все еще используется на 100%.
Любые предложения?
Перезагрузите tomcat, если файл используется, и вы удалите его, пространство становится доступным, когда этот процесс заканчивается.
Как и другие, файл, вероятно, все еще открыт другими процессами. Чтобы узнать, с какими из них вы можете сделать
lsof /opt/tomcat/logs/catalina.out
в котором перечислены процессы. Вероятно, вы найдете tomcat в этом списке.
Возможно, что запущенная программа все еще держится за файл.
В соответствии с другими ответами здесь вы можете просто отключить tomcat, чтобы он не держался за файл.
Если это не вариант, или если вы просто хотите получить более подробную информацию, ознакомьтесь с этим вопросом: Найти и удалить большие файлы, которые открыты, но были удалены - он предлагает некоторые более суровые способы борьбы с ним, которые могут быть более полезными для вашей ситуации.
Файловая система linux/unix рассматривает "открытые" файлы как другое имя для них. rm удаляет "имя" из файла, как показано в дереве каталогов. До тех пор, пока ручки не будут закрыты, файлы все еще имеют больше "имен", поэтому файл все еще существует. Файловая система не извлекает файлы до тех пор, пока они не будут полностью неназванными.
Это может показаться немного странным, но это делает возможным использование таких полезных функций, как включение символических ссылок. Символы могут по существу рассматриваться как альтернативное имя для того же файла.
Вот почему важно всегда ссылаться на ваши языки, эквивалентные close() на дескрипторе файла, если вы закончите с ним. Это уведомляет ОС о том, что файл больше не используется. Хотя иногда это может помочь, что, вероятно, имеет место с Tomcat. Обратитесь к Bill Karwin Answer, чтобы узнать, почему.
В зависимости от файловой системы это обычно реализуется как своего рода счетчик ссылок, поэтому не может быть никаких реальных имен. Это также может быть странным, если такие вещи, как stdin и stderr, перенаправляются в файл или другой поточный поток (чаще всего выполняемый с помощью служб).
Вся эта идея тесно связана с понятием " inodes ', поэтому, если вы любопытный тип, я бы рекомендовал проверить сначала.
Это не работает так хорошо, но вы могли обновлять всю ОС, запускать новый http-демон с использованием новых библиотек и, наконец, закрывать старый, когда больше клиентов не обслуживают это (освобождение старых ручек). http-клиенты даже не пропустили бы удар.
В основном вы можете полностью уничтожить ядро и все библиотеки "из-под" запущенных программ. Но поскольку "имя" все еще существует для старых копий, файл все еще существует в памяти/диске для этой конкретной программы. Тогда это будет вопрос перезагрузки всех сервисов и т.д. Хотя это расширенный сценарий использования, это является причиной того, что в какой-то системе Unix есть много времени на запись.
Перезапуск Tomcat выпустит любой трюк, который Tomcat имеет в файле. Однако, чтобы избежать перезапуска Tomcat (например, если это производственная среда, и вы не хотите, чтобы службы были недоступны), вы обычно можете просто перезаписать файл:
cp /dev/null /opt/tomcat/logs/catalina.out
Или даже более короткий и прямой:
> /opt/tomcat/logs/catalina.out
Я все время использую эти методы для очистки файлов журнала для текущих запущенных процессов сервера в процессе устранения неполадок или очистки диска. Это оставляет только один дескриптор, но очищает фактические данные файла, в то время как попытка удалить файл часто либо не работает, либо, по крайней мере, путает выполняемый процесс журнала записи.
Как заметили в этом потоке FerranB и Paul Tomblin, файл используется, и дисковое пространство не будет освобождено до закрытия файла.
Проблема заключается в том, что вы не можете сигнализировать о завершении процесса Catalina catalina.out
, поскольку дескриптор файла не находится под контролем процесса java. Он был открыт перенаправлением ввода-вывода оболочки в catalina.sh
при запуске Tomcat. Только завершая процесс Catalina, этот дескриптор файла может быть закрыт.
В будущем существует два способа предотвращения этого:
Не разрешать вывод приложений Tomcat в catalina.out
. Вместо этого используйте свойство swallowOutput
и настройте каналы журнала для вывода. Журналы, управляемые log4j, могут быть повернуты без перезапуска процесса Catalina.
Измените catalina.sh для вывода на выход cronolog вместо простого перенаправления на catalina.out
. Таким образом, cronolog будет вращать журналы для вас.
лучшее решение использует 'echo' (как предложение @ejoncas):
$ echo '' > huge_file.log
Эта операция довольно безопасна и быстра (удаляет около 1 Г данных в секунду), особенно когда вы работаете на своем производственном сервере.
Не просто удаляйте этот файл с помощью 'rm', потому что сначала вам нужно остановить процесс записи, иначе диск не будет освобожден.
ссылаются на: http://siwei.me/blog/posts/how-to-deal-with-huge-log-file-in-production
Если что-то еще открыто, файл фактически не исчезнет. Вам, вероятно, нужно как-то сигнализировать каталине, чтобы закрыть и повторно открыть свои файлы журналов.
Если есть вторая жесткая ссылка на файл, она не будет удалена, пока она не будет удалена.
Является ли rm зарегистрированным/запланированным? Попробуйте команду "sync" для принудительной записи.