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

У вас логика «Quod licet Iovi, non licet bovi».

«Вы не должны пользоваться tmp если вам важны файлы!»
«Вы не понимаете, это маунт поинт!»

Ну так а что мне мешает в /tmp хранить MP для своих сервисов? Ой, а мне нельзя, только systemd можно.

кроме как для кэша (а для него вообще-то ~/.cache есть)

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

любое использование /tmp полностью теряет свой смысл, кроме как для кэша

У /tmp никогда не было никакого другого смысла, кроме как для кэша.

Ничто не мешает, просто клинер словит EBUSY и пойдёт дальше.

Ну так и в чем тогда смысл патча выше? Лишний раз поджечь пердаки сделав исключение для systemd потому что они не соответствуют своей же логике?

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

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

У /tmp никогда не было никакого другого смысла, кроме как для кэша.

А вот это совсем бред. Для кэша используется /var/cache. /tmp это именно для временных файлов, обычно мелких, которые хранить как кэш не имеет смысла.

смысл патча выше

Не было никакого патча, эти строчки там с самого начала.

потому что они не соответствуют своей же логике

Если много раз повторить одну и ту же хрень, она не станет правдой.

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

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

А очистка /tmp по таймеру — практика, предшествующая И сабжевой новости, И даже systemd.

Прямо rm -rf /tmp/* по крону? Что-то я такого не видел.

Если много раз повторить одну и ту же хрень, она не станет правдой.

Вы не должны хранить файлы в /tmp если боитесь что их кто-то удалит!
Но вот патч для systemd!
Там просто чтобы не было EBUSY
Но ведь и у меня может быть EBUSY
Это не страшно, пусть будет EBUSY
Но в чем тогда смысл патча?
ВЫ ГОВОРИТЕ ХРЕНЬ! ЭТО НЕПРАВДА!

Никто не говорит про перезапуск программы

Тут уже полтреда люди говорят про перезапуск программы и пытаются ссылаться на FHS, в котором это упомянуто. А я говорю про перезапуск системы, потому что это единственный случай, поведение в котором поменялось в результате сабжа.

Я не понимаю, с чем ты тут споришь

Я тоже не понимаю, с чем ты споришь, кроме того, что «системд бэд». Очистка /tmp по таймеру была уже давно (и в systemd, и в дебиане).

Прямо rm -rf /tmp/* по крону? Что-то я такого не видел.

Я тебе уже написал, что эта практика восходит ещё к юниксам и солярке. И нет, не rm -rf, там тоже было про старые файлы.

Зашел в тред получил по ЕБАСУ!

Любая программа, которая кладёт файлик в /tmp, должна быть готова к тому, что он исчезнет in site-specific manner. Если она к этому не готова — значит, эта программа сломана.

flock

и это гарантировано что скрипт-удалятор будет пытаться тоже взять flock перед удалением?

Значит 99.9% программ, хоть как-то использующих /tmp — сломаны. Никто не рассчитывает на то, что файл, созданный там, тут же будет удалён (или вообще не сохранится). Нет, ну как, программа-то будет, как правило, готова, она не сегфолтнется, не вызовет кернел-паник, полицию и Сатану — она просто завершится с ошибкой, или будет пытаться это файлик сохранить снова и снова (а потом вывалится с ошибкой).

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

Любая программа, которая кладёт файлик в /tmp, должна быть готова к тому, что он исчезнет in site-specific manner. Если она к этому не готова — значит, эта программа сломана.

это эквивалентно тому, что «любая программа должна быть готова к тому что ее файл будет удален сразу же после создания». это /dev/null директория уже

Я тебе процитировал FHS. Если хочешь спорить — иди спорь с авторами этого документа.

В документе не написано «любая программа должна работать при рандомном удалении файлов в /tmp», мне не о чем спорить с авторами FHS, там написано всё правильно. Но помимо FHS есть ещё здравый смысл, и если что-то не запрещено в FHS, это не значит, что это что-то можно и нужно тут же реализовывать. Site-specific manner может быть любым с точки зрения FHS, это верно, но это не значит, что с точки зрения разработчики софта должны учитывать и site-specific manner, который является неадекватным. Что угодно может быть site-specific manner, в том числе и то, чего FHS не касается, можно хоть по крону каждые пять секунд запускать kill -9 на все процессы, но это не значит, что любая программа должна быть к этому готова.

И в Debian это прекрасно понимают. Поэтому реализовали адекватное поведение, берущее в рассчёт atime и flock, а не тупо rm -rf по таймеру.

Да это везде прекрасно понимают, это реализовано не в Debian, а в systemd.

В документе не написано «любая программа должна работать при рандомном удалении файлов в /tmp»

В документе написано, что файлы могут быть удалены. То, что программы должны работать (при любом поведении в рамках стандарта), действительно нигде не написано :-)

А монтирование /tmp на tmpfs – отличный способ просрать кучу памяти за зря.

Ага. А монтирование /tmp на SSD гробит этот самый SSD. Не удивлюсь, если популярность tmpfs начала расти именно с переходом на SSD.

это прорыв

Сколько этого ждал, и вот наконец-то. Дебианодевелоперы — молодцы.

Ага. А монтирование /tmp на SSD гробит этот самый SSD.

Да не, не особо. Лулз в том, что современный говнософт гораздо активнее долбится в своей песочнице в $HOME чем в /tmp. Браузеры особенно этим грешат.

Если это был сарказм, то я его не считал. Вроде достаточно важное изменение. А если нет, то зачем было ждать, что мешало сделать так же и раньше? У меня уже лет 15+ /tmp на tmpfs, например, задолго до того, как это в дистрах стало по умолчанию.

Прямо в новости написано, что openssh и tmux пришлось патчить.

Модифицировали пакеты. Скорее всего просто добавили изменения в настройках очистки /var/tmp при установке этих пакетов, а сами исходники openssh и tmux, по этому поводу, не патчили. В оригинале: «openssh and tmux have been fixed to provide a tmpfiles.d exception to retain their respective files».

SSD сложно ушатать этой мелочью. А вот как раз на HDD это мешает: у тебя какой-нибудь IO-активный процесс, постоянно пишущий и читающий большие объёмы данных на HDD, а тут помимо него головке диска приходится бегать ещё какую-то чушь десятибайтовую записывать в другую область.

Может ли в таких случаях работать кеш? Ведь нет особого смысла делать fflush для tmp?

Просто в пакеты openssh и tmux будут добавлены файлики в tmpfiles.d. Это такой системдш-ный конфиг для автоматического создания временных файлов и каталогов. Предположу, что раньше в пакетах openssh и tmux имелись файлы (или, возможно, пустые каталоги) в /var/tmp, и сами программы ожидают, что они там есть. Теперь эти файлы будут пересоздаваться, если их по таймеру удалило. Костыльненько, конечно, несколько, но вот так.

Он, конечно, будет работать, но всё равно ж раз в N секунд будет сброс на диск, и если основной процесс длительный, это уже ощутимая лишняя помеха. Не критичная, но сказывающаяся на производительности статистически значимо.

Скорее всего определённые временные файлы openssh и tmux в /var/tmp просто никогда не удаляются. Тут кто-то упомянул UNIX сокеты. Но зачем их там вообще создают? Почему не где-то в другом месте?

У /tmp никогда не было никакого другого смысла, кроме как для кэша.

4.2

У тебя с CrX перевёрнутые лайф-таймы у кэша и временных директорий.

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

/tmp - это во вторую очередь случайное место, где храниться временный файл, где «временный» - будет удалён до окончания работы процесса (это не cache, если што). Но в первую очередь это костыль для IPC - для юниксов, не умющих в анонимные файлы без инода, для всевозможных .socket-файлов и прочего мусора.

Любая программа, которая кладёт файлик в /tmp, должна быть готова к тому, что он исчезнет in site-specific manner. Если она к этому не готова — значит, эта программа сломана.

Т.е. systemd готов к тому что systemd-private будут исчезать?

Прямо rm -rf /tmp/* по крону?

На перезагрузке.

TL;DR: ты не умнее разработчиков systemd, успокойся :-)

Это 5.2

У тебя с CrX перевёрнутые лайф-таймы у кэша и временных директорий.

Погоди, у меня-то почему? Я как раз об этом в следующем ответе и сказал.

А так всё верно, да. /tmp — временные файлы, /var/tmp — временные файлы, которые переживают перезагрузку ОС (но всё равно временные), кэш — файлы постоянные, не временные, но потеря которых не влияет на работоспособность программы (например там может быть результат каких-то рассчётов долгих, которого если не окажется, рассчёты будут произведены заново, или например локальная копия файлика, который качается из интернета).

Но зачем их там вообще создают? Почему не где-то в другом месте?

Вообще, их делают обычно в /run

Рак под названием systemd всё разрастается, дебиан сопротивлялся дольше всех. Печально.

Да. И если софт создаёт проблемы для пользователя, это крайне убогий софт. Я согласен с CrX по этому поводу. Удаление файлов во время работы программы – крайне плохая идея.

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

Конечно.

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

Ага, прощай сборка софта в /tmp, прощай шелл-скрипты.

Увидели проблему, там где ее нет.

Проблемы нет, было просто несогласие между юзерами.

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

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

Я вообще то про крон писал …

Но если ВАМ интересно, то могу ВАМ сказать что ВЕСЬ интернет это и есть тот зонд от называемой ВАМИ конторы, и не говорите что ВЫ про это не знали.

Погоди, у меня-то почему? Я как раз об этом в следующем ответе и

Я не видел следующего ответа, и опирался только на

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

исчезать вмести

hobbit try pressing more buttons ;)

Ага, прощай сборка софта в /tmp, прощай шелл-скрипты

Ну если ты там хранишь файлы, то ты сам себе буратино.

Вот тут кто-то несогласен был в 2022. Поясни где он ошибается пжлст. https://forums.fedoraforum.org/showthread.php?328217-What-do-you-do-with-all-the-systemd-private-files-that-are-in-tmp&p=1857769#post1857769

Ну так там продолжение было, что для кэша другие директории. Собственно в том и был смысл, что это неправильно ;)

Поясни где он ошибается

В фактах.

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

Как?

Вообще, их делают обычно в /run

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

Ну, этого просто не происходит. Там написано неверное утверждение.