LINUX.ORG.RU

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

 , , , ,


1

5

Разработчик Debian Лука Боккасси анонсировал переход Debian к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру по умолчанию, начиная с Debian 13 “Trixie”.

В новых системах файлы в /tmp будут либо исчезать вместе с прежним экземпляром tmpfs в памяти после рестарта, либо будут удаляться ежедневно по таймеру, если они старше 10 дней, а файлы в /var/tmp будут удаляться только ежедневно по таймеру, если они старше 30 дней. Пакеты openssh и tmux были модифицированы с целью сохранения своих временных файлов в /var/tmp в качестве исключения. В системах, которые будут обновляться до Debian 13 “Trixie”, старое поведение /var/tmp сохранится.

В то время, как в большинстве других дистрибутивов давно перешли на использование tmpfs в /tmp, в Debian не спешили этого делать. Сейчас разработчики Debian (Michael Biebl и Luca Boccassi) возобновили одну из таких дискуссий 2020 года, в которой разработчик из Canonical (Eric Desrochers) пожаловался на проблему несоответствия тогдашней реализации /var/tmp в Debian тому, как работает systemd, несмотря на то, что патч был опубликован ещё в 2012 году. Таким образом, было принято решение привести поведение системы при работе с этими директориями к общепринятому в systemd и в большинстве других дистрибутивов.

>>> Подробности



Проверено: hobbit ()
Последнее исправление: Virtuos86 (всего исправлений: 7)
Ответ на: комментарий от intelfx

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

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

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

PPP328 ★★★★★
()
Ответ на: комментарий от CrX

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

PPP328 ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

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

CrX ★★★★★
()
Ответ на: комментарий от PPP328

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

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от intelfx

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

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

PPP328 ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от CrX

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

flock

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

asdpm
()
Ответ на: комментарий от intelfx

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

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

CrX ★★★★★
()
Ответ на: комментарий от intelfx

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

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

asdpm
()
Ответ на: комментарий от intelfx

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

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от CrX

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

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

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

intelfx ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

zg
() автор топика
Ответ на: комментарий от zg

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от Infra_HDC

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

CrX ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

zg
() автор топика
Ответ на: комментарий от zg

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

CrX ★★★★★
()
Ответ на: комментарий от zg

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

CrX ★★★★★
()
Ответ на: комментарий от u5er

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

CrX ★★★★★
()
Ответ на: комментарий от CrX

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

zg
() автор топика
Ответ на: комментарий от intelfx

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

4.2

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

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от intelfx

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

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

Gentooshnik ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

LamerOk ★★★★★
()
Ответ на: комментарий от intelfx

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

Это 5.2

firkax ★★★★★
()
Ответ на: комментарий от LamerOk

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

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

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

CrX ★★★★★
()

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

firkax ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

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

noc101
()
Ответ на: комментарий от noc101

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

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

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

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

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от LamerOk

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

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

noc101
()
Ответ на: комментарий от FSBinyourx86

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

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

mx__ ★★★★★
()
Ответ на: комментарий от CrX

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

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

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

LamerOk ★★★★★
()

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

@hobbit try pressing more buttons ;)

aol ★★★★★
()
Ответ на: комментарий от LamerOk

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

CrX ★★★★★
()

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

wandrien ★★
()
Ответ на: комментарий от Gentooshnik

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

intelfx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.