Как очистить tmp linux
Обновлено: 07.07.2024
В любых системах со временем и в процессе работы уменьшается свободное пространство. А это один из тех важнейших ресурсов, за которым системные администраторы должны следить особенно пристально. Порой после установки небольшого пакета оказывается, что за время своей работы этот пакет сгенерировал временных файлов. По объёму в несколько раз больше, чем сам этот пакет. Обычные текстовые log-файлы также могут занимать значительный объём. Если их генерация и хранение не настроены должным образом. Поэтому в системном администрировании очень важно регулярно проводить очистку файловых систем (ФС) от бесполезного объёма данных. Которые отъедают драгоценное дисковое пространство.
Временные и ненужные файлы
Как уже отмечалось, в любой работающей ОС (в особенности в активно работающей) всегда имеются ненужные и/или временные файлы. Так, к примеру в случае каких-либо сбоев системное ядро создаёт файлы с информацией об адресном пространстве программы (дампы памяти) на момент сбоя. Такие файлы обычно имеют имя core, core.pid или program.core. В зависимости от ситуации, в которой произошёл сбой и последующая генерация подобных файлов, их размер может быть в несколько мегабайт, а если сбои не учитывались администратором и происходили часто, то в совокупности теряется внушительный объём свободного пространства, который крайне расточительно отводить для хранения core-файлов, представляющих интерес только для разработчиков и специалистов по отладке программного обеспечения (ПО). В некоторых системах работу системных ядер можно сконфигурировать таким образом, чтобы дампы памяти вообще не генерировались, либо, чтобы они помещались в отдельный каталог и это очень удобно и для разработчиков, отладчиков, а также и для системных администраторов. Для уточнения этой информации следует обратиться к страницам справочного руководства используемой системы с помощью команды man core для Linux или man coreadm для Solaris.
Естественно, подобные скрипты можно запускать и по расписанию, не дожидаясь плановой перезагрузки или технического обслуживания (ТО) серверов, используя cron, что часто и делают многие системные администраторы. Конечно, в таком случае скрипты очистки должны быть тщательно протестированы и соответствовать техническим регламентам, принятым в организации, чтобы исключить вероятность удалить что-то действительно нужное в системе, а также как можно меньше мешать основной работе системы.
Когда используется сетевая ФС NFSv3, то на серверах, которые её обслуживают также могут накапливаться внушительные объёмы ненужных файлов, которые обычно имеют имена, соответствующие «.nfsxxx», где xxx – некоторый числовой код.
Как удалить не нужные файлы
Самым эффективным средством по избавлению от «мусора» в системе по праву считается команда find. Для многих системных администраторов это вторая по частоте использования команда после sudo.
Для удаления неиспользуемых за прошедшие семь дней файлов с именем core можно воспользоваться командой следующего вида:
В данном примере следует обратить особое внимание на параметр -xdev (в некоторых системах -x), который ограничивает использование команды find строго в пределах корневой файловой системы. Всё-таки излишняя осторожность не помешает. Да и вообще такой метод более удобен, когда в системе монтируются множество ФС. В таком случае нужно выполнять приведённую команду отдельно для каждой из файловых систем, поскольку, как правило каталог /var (в котором собирается много ненужных и временных файлов) часто является отдельной ФС — об этом нужно помнить. Параметр type -f указывает удалять только файлы, поскольку в каталоге с исходными кодами есть каталог core (с исходными кодами ядра), имя которого совпадает с маской в приведённой команде find, однако каталог core удалять крайне не желательно.
Для избавления от ненужных и временных файлов, создаваемых различными текстовыми редакторами можно использовать такую команду:
Важно помнить и о том, что если ФС была смонтирована с опцией noatime (для команды mount), то все вышеприведённые команды будут малоэффективны, поскольку опция noatime заставляет смонтированную ФС не хранить временные метки доступа к файлам, а все вышеприведённые примеры учитывают условие, отражающее время доступа к файлам. Поэтому в данном случае нужно усложнять условия поиска для команды find.
Следующая команда удаляет все подкаталоги каталога /tmp, причём только те, к которым не было обращений более трёх дней:
В данном примере присутствует маска для исключения подкаталога lost+found. Это очень важно, т. к. этот подкаталог будет присутствовать в /tmp, в том случае, если /tmp является отдельной файловой системой. Естественно каталог lost+found ни в коем случае не должен быть удалён.
Если после проделанных выше действий у вас в системе не освободилось необходимого места, то ищем большие каталоги и файлы как это сделать читаем в этой статье
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Я использую оперативную память для моих tmpfs /tmp, 2 ГБ, если быть точным. Обычно этого достаточно, но иногда процессы создают файлы там и не могут очистить после себя. Это может произойти, если они потерпят крах. Мне нужно удалить эти потерянные tmp файлы, иначе в будущем /tmp не хватит места.
Как я могу безопасно собрать мусор / TMP? Некоторые люди делают это, проверяя отметку времени последнего изменения, но этот подход небезопасен, поскольку могут существовать длительные процессы, которым все еще нужны эти файлы. Более безопасный подход - объединить условие отметки времени последней модификации с условием, что ни у одного процесса нет дескриптора файла для файла. Есть ли программа / скрипт / и т.д., которые воплощают этот подход или какой-то другой подход, который также безопасен?
Кстати, разрешает ли Linux/Unix режим открытия файла с созданием, при котором созданный файл удаляется при завершении процесса создания, даже если он произошел сбой?
Вы можете попробовать что-то вроде этого:
find используется для поиска файлов, которые соответствуют определенным критериям.
К последнему пункту: Учтите, что могут быть файлы, которые записываются только один раз (например, при загрузке системы), но часто читаются (например, любой файл X-session-cookie). Поэтому я рекомендую добавить некоторые проверки имен, чтобы они влияли только на файлы, созданные неисправными программами.
edit2: К вашему последнему вопросу: файл не будет удален с диска, пока ни у какого процесса не будет открытого дескриптора к нему (по крайней мере, для родных файловых систем linux). Проблема заключается в том, что запись в каталоге удаляется немедленно, а это означает, что с момента удаления файла новые процессы больше не смогут его открыть (поскольку к нему не прикреплено имя файла).
edit3: Но что, если я хотел бы автоматизировать весь процесс?
Как я уже сказал, могут быть файлы, которые записываются один раз, а затем читаются время от времени (например, файлы cookie сеанса X, файлы PID и т.д.). Они не будут исключены этим небольшим скриптом удаления (по этой причине вам может понадобиться выполнить тестовый прогон с echo прежде чем фактически удалять файлы).
Если вы хотите использовать atime , я бы порекомендовал иметь /tmp на отдельном разделе (в идеале, на виртуальном диске), чтобы влияние на производительность системы не было слишком большим.
Но имейте в виду, что нужно проверить команду с помощью echo прежде чем вы удалите все, что нужно вашей системе!
Да, окна приложений, которые не имеют соответствующих значков, WM_CLASS и других наборов метаданных, должны считаться ошибкой в приложении, которое предоставляет эти окна.
Каталог по умолчанию очищается при каждой загрузке, потому что TMPTIME по умолчанию 0.
Здесь вы можете изменить время в следующем файле:
TMPTIME указывает, как частоту tmp dir может быть очищена в днях
Очистка при каждой загрузке не идеальна для машины, которая никогда не перезагружается, как сервер. У меня более 500 000 файлов, занимающих 5 Гб места в моем / tmp, потому что у моего сервера 378 дней работы. Я не хочу перезагружать его, просто потому, что очистка этих файлов при перезагрузке занимает несколько часов. – rjmunro 25 January 2012 в 17:47 Задача CRON может легко решить эту проблему. – Ken Sharp 8 March 2014 в 20:27 Также tmpwatch должен быть подходящим инструментом. – ArekBulski 28 October 2015 в 16:29Хотя папка /tmp не является местом для хранения файлов в течение длительного времени, иногда вы хотите сохранить что-то немного дольше, чем в следующий раз при перезагрузке, что является по умолчанию для систем Ubuntu. Я знаю, что время или два я загрузил что-то в /tmp во время тестирования, перезагрузился после внесения изменений, а затем снова потерял исходные данные. Это можно изменить, если вы хотите, чтобы ваши файлы /tmp были немного длиннее.
при следующем перезагрузке
Значение по умолчанию, которое говорит, что ваша система очистки /tmp при перезагрузке хранится в файле /etc/default/rcS.
Текущее значение TMPTIME=0 указывает на удаление файлов при перезагрузке, несмотря на возраст файла. Изменение этого значения на другой (положительный) номер изменит количество дней, в течение которых файл может выжить в /tmp.
Этот параметр позволит файлам оставаться в /tmp, пока они не станут недели, а затем удалить их при следующей перезагрузке. Отрицательное число (TMPTIME=-1) сообщает системе никогда ничего не удалять в /tmp. Это, вероятно, не то, что вы хотите, но доступно.
То есть бывают действительно критические ситуации — в этих условиях перестают нормально работать многие программы и службы. Поэтому задача становится следующей: срочно любой ценой освободить место на диске, чтобы можно было продолжить обслуживание системы и перейти ко второму этапу — поиску директорий и папок, которые привели к этой проблеме из-за того, что стали занимать слишком много места.
Предупрежу заранее: следующие команды хотя в основном и удаляют бесполезные файлы, после их выполнения могут потребоваться такие действия как:
- перезапуск служб для их нормальной работы (чтобы они заново пересоздали файлы журналов, кэши, файлы блокировки)
- могут быть потеряны различные журналы и файлы из корзины, которые хотя и не нужны большинству пользователей, в некоторых условиях вы можете захотеть их оставить (например, вам важно изучить файлы логов, поскольку в них может быть причина проблемы).
Это означает, что НЕ копируйте бездумно команды — читайте пояснения к ним и оценивайте, насколько они безболезненны для вашей ситуации.
1. Удаление временных файлов
Файлы в папке /tmp/ будут удалены в любом случае при следующей перезагрузки системы. То есть с одной стороны их можно удалить достаточно безболезненно:
НО: может быть нарушена работа программ, которые запущены в настоящее время и которые сохранили какие-то данные в папку /tmp/.
2. Удаление файлов кэширования
В директории /var/cache/ много поддиректорий, которые можно удалить практически безболезненно (данные утеряны не будут, а программы создадут новые файлы кэширования). Эта директория вызывает особый интерес, поскольку на которых системах кэши разрастаются на гигабайты и десятки гигабайт. Иногда поиск проблемной директории в /var/cache/ может окончательно решить ситуацию с нехваткой места на диске.
Для удаления кэша шрифтов:
Для удаления кэша установочных пакетов (на Debian, Linux Mint, Ubuntu, Kali Linux и их производных):
Для удаления кэша установочных пакетов (на Arch Linux, BlackArch и их производных):
Удаление кэша справочных страниц:
Вы можете продолжить поиск больших кэшей применимо к программному обеспечению, установленному на вашей системе. Например, это могут быть кэши веб-сервера, прокси-сервера и т. д.
3. Удаление логов (журналов)
На веб-серверах могут разрастись слишком сильно журналы веб-сервера.
Для удаления логов Apache на Debian, Linux Mint, Ubuntu, Kali Linux и их производных:
Для удаления логов Apache на Arch Linux, BlackArch и их производных:
Чтобы сервер начал создавать новые файлы журналов и записывать в них, нужно перезапустить службу веб-сервера.
В зависимости от интенсивности использования системы, накопленные журналы могут занимать гигабайты. В зависимости от системы файлы могут называться по-разному, более точный анализ рекомендуется выполнять с помощью утилиты ncdu:
4. Очистите корзину
Этот совет больше для настольных систем. Файлы, которые вы удалили в графическом интерфейсе рабочего стола, попадают в папку
/.local/share/Trash/files/, вы можете проанализировать их и при желании удалить (второй раз):
5. Удаление ненужных файлов исходного кода заголовков ядра
Следующее актуально только для Debian, Linux Mint, Ubuntu, Kali Linux и их производных. Проверьте папку /usr/src/, там будут подпапки вида linux-headers- - большинство из них можно удалить — оставьте только ту, номер которой соответствует текущему ядру системы — обычно это самый последний номер выпуска.
6. Удаление осиротевших пакетов
Осиротевшие пакеты — это те пакеты (программы), которые устанавливались в качестве зависимостей для других программ. Но по разным причинам они больше не нужны: или удалена программа, которая их использовала, или для той программы они перестали быть зависимостями после обновления программы.
На Debian, Linux Mint, Ubuntu, Kali Linux и их производных удалить ненужные пакеты можно следующим образом:
Для Debian и производных предыдущая команда абсолютно безопасна.
В Arch Linux и производных список осиротевших пакетов можно увидеть следующим образом:
Прежде чем переходить к их автоматическому удалению, настоятельно рекомендуется изучить этот список!
Для рекурсивного удаления сироток и их конфигурационных файлов в Arch Linux и производных:
Если осиротевшие пакеты не были найдены, pacman завершит работу с ошибкой: ошибка: не задано целей (для справки используйте -h). Это ожидаемо, поскольку pacman -Rns не получил аргументов.
7. Очистка журналов systemd
Со временем, в некоторых системах логи системы начинают занимать гигабайты на жёстком диске. Просмотреть журналы и освободить место вы можете с помощью команды journalctl, подробности смотрите в статье «Как использовать journalctl для просмотра системных логов Linux».
Чтобы увидеть, сколько место занимают журналы, выполните:
Чтобы удалить все записи, оставив только записей на 100 мегабайт, выполните:
Либо для удаления всех записей в системном журнале, старше одной недели:
8. Файлы в директории /lost+found
В папку /lost+found сохраняются файлы, которые были найдены после проверки файловой системы диска. Обычно такие проверки выполняются после внезапной перезагрузки системы или в случае признаков проблем с диском.
Найденные файлы обычно повреждены. Их цель — сохранить данные, которые в случае исправления ошибок на файловой системе были бы совсем утеряны.
Папка /lost+found может быть пустой (если не было проблем с диском). В случае если там есть файлы, то вы можете их просмотреть и, при желании, удалить.
9. Очистка PHP сессий
Иногда веб-приложений из-за бага могут создать бесчисленное количество сессий. Проверьте директорию /var/lib/php/sessions/ на предмет слишком большого количества файлов.
(БОНУС) 10. Проанализируйте файлы Docker
Самой большой папкой является /var/lib/docker/overlay2/. Для анализа занимаемого места на диске выполните:
Заключение
Итак, мы рассмотрели, какие файлы можно удалить из Linux практически без потери информации. Кроме рассмотренных директорий, которые можно очистить как на удалённой системе с веб-сервером, так и на домашнем компьютере, пользователям с графическим рабочим столом следует обратить внимание на такие директории как:
Их НЕ нужно удалять, но стоит проанализировать. Например, вы можете выяснить, что веб-браузер на вашем компьютере имеет кэш в несколько гигабайт и что вы можете их освободить (рекомендуется делать средствами веб-браузера, а не удалять файлы напрямую).
Если я пропустил какие-то директории с файлами, которые можно безболезненно удалить, то пишите их в комментариях!
Читайте также: