Проблемы со свободным местом /var

https://access.redhat.com/solutions/2316

Пробовал данный способ, удалось освободить 3,5 ГБ памяти, однако, проблема остаётся.

Ставь утилиту ncdu, запускай её в /var и смотри, кто сколько ест.

Есть вариант это сделать без сторонних утилит, так как нет возможности что-то установить?

Flatpak?

Флатпак же в хомяках живёт обычно.

Чего? А не снап?

Мне уже указывали тот на то, что из-за флатпака показывает занятое место, а фактически свободно. Чего-то там перемудрили

Никогда не юзал снап, но мой флатпак точно загаживал в хомяке в местах типа ~/.var.

А файл-менеджер типа mc стоит? Так было бы проще.

Да, стоит mc

du -shx /var/*

du -shx /var/* | sort -h

Тогда попробуй в mc выбрать подкаталог и жамкнуть ctrl + space, он скажет, сколько весит. И так найдёшь проблему.

«Всякая веревка, порезанная на куски, окажется слишком короткой.»

Но ты уже сам ответил:

/var сделан как отдельная точка монтирования…

Можно конечно ответить вопросом на вопрос, а нафига ты его делал, если не имеешь понятия нафига?.. Могу разворачивать бесконечно…

Можно конечно ответить вопросом на вопрос

А можно перестать постить бесполезный тупняк. Предлагаешь сделать /var на 10 Тб, чтобы вопрос «куда пропало место?» возникал позднее?

На вопрос «нафига я этот делал» сказать ничего не могу, так было до меня, менять это варианта нет, машина должна работать 24/7, резервной нет. Вопрос был не в том, что выделено мало места и его надо как-то увеличить, а в том, что какие-то непонятные файлы занимают на /var место, хотя сама директория весит не больше 7 ГБ, я ищу способ понять, почему в df занято 87 из 92 ГБ, хотя по факту там 7 ГБ даже не наберётся

машина должна работать 24/7, резервной нет

Передавай привет владельцам/руководству

Ты правильно ответил сам себе: «перестать постить бесполезный тупняк». Да только по тупости, сам не понял.

Посмотрел через команду du -sh /var/* размер всех подкаталогов, их суммарный вес 6,1 ГБ, при этом df -h показывает, что использовано 84 ГБ. Сочетание клавиш в MC почему-то не работает(((

Частенько возникает такой вопрос от любителей накрошить разделов. Поищи на форуме.

Открытые удаленные файлы занимают место. Ребут и всё в порядке. Потому что это тебе, судя по скиллам, будет не под силу.

Возможно там так логи ротируюся, что писать продолжает в удалённый файл. Тогда это 1) воспроизведётся, 2) потеря логов.

Но, да, с учётом «линуксом пользуясь впервые», ребут это дёшево и сердито.

А вообще, что за файловая система? Может у тебя btrfs со снапшотами?

машина должна работать 24/7, резервной нет.

А машина об этом вкурсе, что она должна? А в целом у меня для вас плохие новости.

Этот способ помог освободить только несколько ГБ. Сегодня перезагружали, не помогло.

Сегодня перезагружали, не помогло.

Видел такое пару раз на xfs, помог xfs_repair

Ты правильно ответил сам себе: «перестать постить бесполезный тупняк». Да только по тупости, сам не понял.

Твоя основная проблема в том, что ты высказываешь мнение, не разбираясь в вопросе. Анонимус мудр

lsof 2>/dev/null | grep /var | grep DEL

Сдается мне у тебя там куча файлов(например логов), которые были удалены до того, как дескрипторы были закрыты. В следствии чего запись в них ПРОДОЛЖАЕТСЯ, только ты их не видишь :-)

Смотреть какой лог забивается. Вангую что parsec. Сделать ротацию.

Проблемы со свободным местом /var (комментарий)

Тред не читай - сразу отвечай :-)

Ну, тогда только смотреть глазами что и где занято, с пониманием что можно удалить, а что - нет. Автору скорее всего будет тяжко...

Этот способ помог освободить только несколько ГБ. Сегодня перезагружали, не помогло.

Ты так и не ответил какая там файловая система. Если дефолтная ext3/ext4 то делай fsck -f разделу, если другая то там возможно другая команда проверки. Чтобы сделать fsck, надо, увы, будет отключить на время полезную нагрузку сервера, ребутнуться либо с livecd либо через init=/bin/bash в аварийный режим с read-only разделами.

Ну и ещё если файловая система с поддержкой снапшотов (zfs, btrfs и не знаю какие ещё) то возможно место занимают снапшоты и их надо удалить.