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

И особенно нравится вот это:

Not doing so has been allowing unnecessary junk files to clog up the local storage.

Это, блджад, мой storage! И как именно его засирать решаю я, а не сборище радужных трансов! Пц, совсем в сторону Микрософта скатываются уже.

А не так ли появился /var/tmp? Ну типа /tmp то чистят по хрону, а там понадёжней...

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

Удалять файлы полнейшая глупость.

Тоже такподумал: а если моей программе надо временные данные дольше 10 дней хранить? Что за Нафиг вообще?

Ты ведь понимаешь, что речь здесь в первую очередь о системных программах, у которых нет никакого ~

Так, а собственно куда тогда, если не в /tmp и /var/tmp?

Прекрасно разбирается. Ведь можно поставить tmpfs размером в 25гб, что примерно вдвое больше корня который я обычно выделяю. А свопа у меня вообще 37гб, ну так просто, чтобы выгорал помедленнее и точно никода не кончился. А для 1Тб диска зарезервировать 10% под своп + временные файлы вполне себе нормально если это ссд.

Так ничего же не меняется! Вот ты раьш настраивал /tmp вручную в дебиане, и вот сейчас ты тоже будешь настатвать /тап вручную.

Ещё по хорошему надо слить туда же кеш браузеров.

У меня в фаерфоксе давно кэш в памяти. В about:config:

• browser.cache.disk.enable → falsa
• browser.cache.memory.enable → true (оно вроде так по умолчанию, но всё же)
• browser.cache.memory.capacity → Желаемое значение (у меня 262144)

Проверить, что настройки вступили в силу: about:cache

Любая, кроме системд? И ещё кстати любого более-менее продвинутого WM и ДЕ. И размеется Х11.

Так кеш не сохранится между перезапусками браузера. А на моей памяти не течёт только фокс-60, остальные лучше перезапускать каждую неделю, что сильно чаще чем ОС.

Ну и кеш миниатюр + иконок + qml часто жирнее кеша браузера.

З.Ы. Забыл, у меня же почти во всех многоклеточных скриптах временные файлы в /tmp хранятся. Ну там подскрипты отдельных потоков, вызываемых задач, файлы блокировки, списки и некоторые переменные...

Ведь можно поставить tmpfs размером в 25гб, что примерно вдвое больше корня который я обычно выделяю.

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

Ты всегда всё сразу через жопу пытаешься делать или у тебя бывают нормальные идеи?

А для 1Тб диска зарезервировать 10% под своп + временные файлы вполне себе нормально если это ссд.

Зачем, если можно это место забить чем-то полезным? И зачем резервировать-то? Своп можно добавлять и удалять по необходимости. В моём случае он тупо не нужен большую часть времени, поэтому у меня его и нет.

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

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

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

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

не факт, что в своп отправятся они, кстати

С вероятностью в 99,9% в самую первую очередь. Да, возможен трешинг если они в этот момент будут активно использоваться, но такое встречается пару раз в год (или просто проглатывается zswap).

откуда их будет по необходимости ядро подтягивать в файловый кэш в памяти?

Просто исключаю операцию, которая может вообще не понадобиться или понадобиться не сегодня - собственно запись на диск по таймауту синхронизации ФС.

Не, серьёзно, схема очень хорошо зарекомендовала себя с 2010-2012 годов, тогда ещё на hdd. Как с недостатком так и с избытком оперативки.

В моём случае он тупо не нужен большую часть времени, поэтому у меня его и нет.

Он нужен чтобы не словить полный финишь в ту самую меньшую часть времени. Внезапный oom-killer ничем не лучше внезапного ресета.

Зачем, если можно это место забить чем-то полезным? И зачем резервировать-то?

Потому что я уже выжег один ссд сделав так, как ты предложил. Не зарезервировал и забил чем то полезным. А свопа оставил всего 2Гб, ведь при 8Гб оперативки он один хрен никогда не использовался. Почти никогда... Да всего то одна програмка всего то 2 недели...

Он нужен чтобы не словить полный финишь в ту самую меньшую часть времени. Внезапный oom-killer ничем не лучше внезапного ресета.

Нет? У меня OOM в основном убивает самые жручие процессы, а не вообще всё. Так что вот с этим у меня проблем не возникало.

Потому что я уже выжег один ссд сделав так, как ты предложил.

Так ты же покупаешь самые дерьмовые SSD на рынке.

Так кеш не сохранится между перезапусками браузера.

Да. Но я его перезапускаю только когда он обновляется, так что норм.

А на моей памяти не течёт только фокс-60, остальные лучше перезапускать каждую неделю, что сильно чаще чем ОС.

Это не совсем такая течка. Решается так: about:memory → кнопочка «Minimize Memory Usage».

Ну и кеш миниатюр + иконок + qml часто жирнее кеша браузера.

Возможно. У меня такого нет. Вообще у меня ~/.cache в tmpfs смонтирован.

А больше всего там набегает от borg и от paru. От последнего периодически удаляю, сразу после того, как что-то большое собралось и успешно установилось. Остальное считанные мегабайты: mesa_shader_cache, deadbeef с тумбами обложек и вейвформами по 5–20 мб, а остальное прям совсем-совсем мелочь.

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

Не-а. Стандарт говорит лишь то, что это НЕнадёжное хранилище в контексте более чем одного запуска программы.

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

При чем тут разные «invocations of the program»? Больше 10 дней программа не может работать?

Я не имел ввиду противоречие, а сам факт нужности еще одного мана от systemd.

И периодическое удаление файлов не запрещено в hier(7) (ну и в https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index тоже).

Это обычный каталог. Стандарт лишь говорит, что /tmp может быть чистым при запуске программы. Все.
Про то, что он какой-то ненадежный, что файлы от туда могут пропадать во время работы программы нигде не говорится.

systemd, конечно, много чего тащит, и с основным посылом я согласен, но где в сабже противоречие с hier(7)?

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

Да-да, мы уже обсудили. Только причём тут вообще этот стандарт тогда? ;)

Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

Как я понимаю, то тут речь идет о реализации. А именно, что удалять их можно после выхода программы, при shutdown или при загрузке или еще как-то. Они рекомендуют при загрузке.
Удаление *во время работы* программы под эти условия не попадает и явно противоречит стандарту.

x /tmp/systemd-private-%b-*

Пацаны, а я знаю, как мы можем сохранить свои файлы ))))

data stored in /tmp may be deleted in a site-specific manner

Т.е. имеется в виду не unlink, а именно ВНЕЗАПНОЕ удаление ДАННЫХ.

Здравый смысл подсказывает что так. Но по тексту выходит что данные могут быть удалены и во время работы программы.

Где это выходит-то? Этого *нет* в стандарте. Интел придумал, что site-specific про любой момент — нет, это про реализацию (при загрузке, при выключении и т. д.).

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

зы а они уже про жк мониторы знают?

Ненужно. Кто купил 128 гига сам может в фстаб строчку написать

В том и дело что этого нет в стандарте. А значит данные могут быть удалены в т.ч. во время работы программы. Запрета на это в стандарте тоже нет.

Я перестал уже понимать, чем вам всем мешает ЯЗЫК ПРОГРАММИРОВАНИЯ, это же инструмент просто

Да что уж там, из компьютера может вылезти сам RMS, одетый в костюм школьницы, и трахнуть юзера в глазницу. На это запрета тоже ведь нет!

А потом вообще невозможно будет линэксом пользоваться. Мало того, что зрение убивает весьма извращённым образом, так ещё и поддержки средств для слепых в Wayland нет.

Это так не может работать. Иначе можно сделать следующее утверждение основываясь на такой логике: /etc не запрещает удаление файлов по Понедельникам, следовательно такое поведение допустимо.

Чистить при ребуте это логично, ещё более логично что оно чистится само фактически ибо tmpfs, но вот принудительное стирание… Учитывается ли то что файл используется программой в течении большего времени чем 10/30 дней?

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

Вот тут очень некрасиво, костыли с самого начала. Есть наверняка кучи ПО долгоиграющие которые предполагают что их файлы в /tmp будут уничтожены либо в промежутке между запусками, либо при перезагрузке, но никак не по cron`у

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

и к очистке /tmp и /var/tmp по таймеру по умолчанию

Это типа лотеря такая. Повезёт - уцелеет файл, не повезло - ну, извини. /tmp - не место для дискуссий работы.

Нельзя, потому что в /etc удаление файлов вообще не упомянуто, а в /tmp - упомянуто.

А запрет чистить /home по таймеру в стандарте есть? У меня - бизнес-план.

В стандарте не упомянута чистка /home, а чистка /tmp - упомянута.

А почему она там должна быть упомянута? Вы там файлы штоле храните? А облака вам на что дадены?

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

к очистке /tmp и /var/tmp по таймеру

Пипец маразм

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

То есть, «операция», по твоему, месяцами длиться не имеет право. Тааак. А сколько имеет? Назовите вашу сумму, пожалуйста.

Я имел ввиду удаление.

А если «операция» длится допустим секунду, но как раз в эту самую секунду сработал таймер и вот НИПАВИЗЛО, панимаишь.

Нельзя, потому что в /etc удаление файлов вообще не упомянуто, а в /tmp - упомянуто.

Не просто упомянуто, а четко обозначено когда файлы пропадают.

Открытый файл не удалится, система не даст.

Чойта он не удалится? Какая система, кому не даст?

Я вот не знаком с операциями что дляться месяцами. А ты? И во вторых, как я уже написал, открытый файл не удалится. Система не даст!