Debian переходит к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру

А разве сокеты и прочие ipc-каналы не должны создаваться где-то в /run?

Кэш который переживает перезагрузку уже не кэш.

Очевидно, что твоё понимание термина «кэш» сильно отличается от обещпринятого. Предлагаю помедитировать над следующим вопросом:

Следует ли удалять весь кэш кэширующего веб-прокси, через который в интернет по диалапу на V.34+ выходит локальная сеть предприятия?

Заодно, советую посмотреть на срок жизни кэша своего брозуера.

Спор был не про хранение. Или вникни в контекст или забей.

Ну или так: добавь в incrontab удаление любова файла в /tmp по событию его закрытия. И посмотри, как здорово всё стало работать.

Во времена появления /tmp /runа не было.

Кэш может как быть предназначенным для того чтобы переживать перезагрузку, так и не переживать. Здесь нет противоречия никакого. Это не настолько узкое понятие

Кэш который переживает перезагрузку уже не кэш.

Угу. Начинай удалять /var/cache/pacman/pkg/* (или аналог для своего дистрибутива) при перезагрузке.

Ну это не показательный пример.

Это не настолько узкое понятие

Это настолько узкое понятие. Есть чёткий формальный критерий:

Инода с файлом должна быть удалена, как только работа с инодой или содержим файлом закончена - это «временный файл».
Мы положим данные на диск, чтобы не рассчитывать / выкачивать их повторно, а удалим когда-нибудь потом - это кэш.

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

Открытый файл не получится удалить

Виндузятник спалился?

Вполне показательный. Кэш — это данные, которые не имеют ценности и легко могут быть восстановлены (выкачаны из интернета, сгенерированы заново, прочитаны с медленного носителя), но присутствуют для каких-то оптимизаций (скорости, уменьшения I/O, экономии трафика и т.д.).

Слушайте, у вас тут тема имени тупняка или чо? Я только зашел, а тут уже такой праздник.

Чел всё верно говорит, пока у тебя есть живой дескриптор, инод и соответствующие данные будут удержаны от удаления.

некоторые ОС по дефолту не сохраняют кэш пакетов

Люблю дефолтные настройки оставлять, от дистрибутива. Надеюсь, они там будут хороши.

Да, и это нормально. Но пример всё равно вполне валидный. В арче тоже можно его после каждого обновления чистить. Уверен, кто-то даже так делает.

Мы положим данные на диск, чтобы не рассчитывать / выкачивать их повторно, а удалим когда-нибудь потом - это кэш.

Это может как предполагать возможность использования этого файла после перезагрузки, так и не предполагать.

Правильно. А вот в отношении временных файлов мы точно знаем, что после перезагрузки программы с этими же инодами работать больше уже не будут.

Не говоря уж о том, что кэш вообще не только в файлах бывает.

Да, бывает ещё в памяти, но как это влияет на разницу между временным файлом и файловым кэшем?

P.S. Копируй, на что отвечаешь, чтобы телепатию не подключать.

P.P.S. Для полноты картины поправлю формулировку:

Инода с файлом должна быть удалена, как только работа с инодой или содержим файлом закончена - это «временный файл».

Или же файл получит другое имя и продолжит свою жизнь уже как «полноценный» не временный файл с какими-то нужными данными.

А? Что? Уже? Всего то 6 версий прошло как я начал пользоваться этой функцией... Хотя таймер с моим мегасвопом проще вообще отключить.

Пакеты openssh и tmux были модифицированы с целью сохранения своих временных файлов в /var/tmp в качестве исключения.

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

На автоматическую очистку, снижение io диска (и фрагментации фс) и разумеется ускорит все операции с ними пока в системе есть избыток оператвки. А с современным «ну 64гб наверное хватит для десктопа» это будет почти всегда и почти у всех.

P.S. Копируй, на что отвечаешь, чтобы телепатию не подключать.

Дык это… Вверху же «Ответ на комментарий (ссылкой) на…». Я когда на конкретные предложения отвечаю, цитирую, а когда на весь пост — нет…

Да, бывает ещё в памяти, но как это влияет на разницу между временным файлом и файловым кэшем?

P.P.S. Для полноты картины поправлю формулировку:
[…]

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

Ещё один камень в его огород. Ему вообще не следует никуда срать, к тому же не для него ли создавали целый /run?

/run существовал задолго до systemd ;)

А вот почему он срёт в /tmp вместо /var/run — это хороший вопрос.

Вот имею тот же вопрос.

Да нет, он скорее всего о том, что в винде удалить открытый файл сложно (но возможно кстати тоже). А если он даже о том, о чём ты - то это тоже глупость. Если проге файл нужен только как анонимное хранилище данных, то она его сразу невидимым и создаёт (точнее удаляет через мгновение после создания), и все эти чистки вообще мимо. А если у файла есть имя, то наверно оно для того, чтоб его кому-то другому сообщить и тот мог подключиться.

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

Зачем cp вместо ln -s?

/run не использовался до появления системд в дебиане.

>>> Кэш который переживает перезагрузку уже не кэш.
>> Очевидно, что твоё понимание термина «кэш» сильно отличается от обещпринятого

в понятие кэша не входит его выживаемость или невыживаемость между перезагрузками.

Тогда в чём смысл твоей ремарки, если ты повторяешь мой тезис?

не будет работать?

Я не повторяю, но и не оспариваю. Это было дополнение/уточнение, больше для noc101 (и остальных, кто будет читать тред). Надо было, наверное, лучше на его пост отвечать, чтоб не было недопонимания.

Будет, конечно. Но я спрашиваю, зачем это в данном случае, а не говорю «ай-ай-ай, никогда так не делай».

А чего все раскукарекались, удаление старых файлов (больше 30 дней atome/mtime) было еще до системд.

Тогда о чём вообще речь в /var/tmp?

Не, некоторый софт делает сокеты и в /tmp. Тут кто на что горазд. Но канонично для этого есть директории /var/run и /run.

Какому?

Вот! Сначала нужно было написать стандарт по путям файлов и в дальнейшем лет 10-15 не менять его и следовать. А то редкостное бл**во когда Поттеринг чего то там перепридумывает, пути меняются и нужно переписывать софт.

Эх, торопится демьян, суетится, понабрали смузехлёбов!

Так блэт! А где мне порно теперь хранить?

Своп очень легко разбирается с этим конфликтом. А ситуации ускорения и экономии и/о более частые даже при недостатке памяти.

А зачем монтировать в такое место? Ну очевидный же способ огрести конфликтов.

В исключения добавить же, как это сделано для openssh и tmux :)

Не, некоторый софт делает сокеты и в /tmp. Тут кто на что горазд. Но канонично для этого есть директории /var/run и /run.

Зачем же подстраиваться под кривой софт, когда это можно исправить либо на уровне пакета, либо попросить в апстриме?

Да нет, не разбирается. Можно поставить ограничение по размеру в tmpfs, но тогда можно получить ситуацию, когда /tmp засрался и проще ребутнуться.

Засрать же /tmp на терабайтном диске чуток сложнее.

Не, некоторый софт делает сокеты и в /tmp. Тут кто на что горазд. Но канонично для этого есть директории /var/run и /run.

/run появился в FHS 3.0 (2015-ый год), /var/run в FHS 2.3 (2004-ый).

Софт, который метит на совместимость со всякими ClosedBSD и прочими Sunlaris, в апстриме FHS не пользуется и серит прямо в /tmp. Его обычно пачтат для пакетов.

P.S.

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

Понимаешь ли, в чём проблема. В лялексе почти весь софт кривой. Поэтому systemd вызывал столько боли и страданий в первые лет 5 своего существования: он накладывает куда более строгие ограничения на работу программ под ним, чем существовали до него. Иногда эти ограничение даже оправданны, но очень часто – нет.

Зачем же подстраиваться под кривой софт

Так может надо перестать шатать всё и вся, чтоб софт не становился кривым после очередных гениальных изменений, как считаешь?

Дебилиан в своём репертуаре. Сто лет как можно задать RAMTMP=yes в /etc/default/tmpfs для тех, кому это надо. Но нееет, надо принудительно всех осчастливить «совместимостью» с системГ.

Софт, который метит на совместимость со всякими ClosedBSD и прочими Sunlaris, в апстриме FHS не пользуется и серит прямо в /tmp.

Солярка мертва, БСД в среднем тоже. Зачем с ними делать совместимость? Кстати, в BSD есть /var/run.

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

Ну.. в том виде, в котором они есть в Debian, они и правда ненужны.

там условие, что если они старше 10 и 30 дней соответственно. Тогда норм.

У меня 80-90% /tmp занято кешем иконок, миниатюр файлов и некими временными файлами QT/KDE. Ещё по хорошему надо слить туда же кеш браузеров. Идея вычистить всё это по аптайму системы очень классная.

Я не понимаю. То есть теперь, если программа работает месяцами, и использует /tmp для хранения временных файлов, то ее работа будет нарушаться вот этой вот бодягой?

Сто лет как можно задать RAMTMP=yes в /etc/default/tmpfs

Можно, но нужно ещё не забыть:

# TMPFS_SIZE=95%VM 
TMPFS_SIZE=63G  

Солярка мертва, БСД в среднем тоже. Зачем с ними делать совместимость?

Зачем ты меня об этом спрашиваешь? У меня нет ответа на этот вопрос.

в BSD есть /var/run.

Во всех *BSD до единого?