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)

Не очень понятно, перешли на systemd что ли ? Или как ? Может им доки почитать для начала и узнать что systemd есть встроенный cron называемый тут timer ?

Глянул тут у себя, забыл уже как давно все это настраивал :(

 [Timer]
 OnCalendar=daily
 Persisternt=true
 OnBootSec=15min
mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 1)
Ответ на: комментарий от mx__

Не очень понятно, перешли на systemd что ли ? Или как ? Может им доки почитать для начала и узнать что systemd есть встроенный cron называемый тут timer ?

Возможно это я неправильно прочитал. Про cron там не сказано, сейчас исправлю.

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

эээ, извините но Вы там поосторожнее с правками то. Я по ссылке не ходил, просто прочитал новость на ЛОРе ;)

mx__ ★★★★★
()

А на что это повлияет? Я правильно ли понимаю, что хранение чего-либо в /tmp и /var/tmp априори считается ненадёжным. То есть никакая программа не должна рассчитывать на сохранность данных хранимых там сколь-нибудь продолжительное время.

Camel ★★★★★
()

«исчезать вместЕ с прежним».

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

systemd есть встроенный бэкдор АНБ наравне с командой sudo для «проходной» двери в linux других юзеров спецслужбам, эх, как жаль что Gentoo стала использовать Rust, хорошая же была ос

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

То есть никакая программа не должна рассчитывать на сохранность данных хранимых там сколь-нибудь продолжительное время.

Ага, вот только тот же systemd срет туда данные своих сервисов.

$ ls -la /tmp | grep systemd
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-bolt.service-YzQGmh
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-colord.service-1c6hqj
drwx------  3 root root      4096 мая 27 13:17 systemd-private-220ba69094964cefbaa73ef32259c26e-fwupd.service-9Oqcej
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-ModemManager.service-1zgQri
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-systemd-logind.service-olJVCh
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-systemd-resolved.service-FQewoj
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-systemd-timesyncd.service-gNernf
drwx------  3 root root      4096 мая 26 22:46 systemd-private-220ba69094964cefbaa73ef32259c26e-upower.service-DDWhGh

PPP328 ★★★★★
()
Последнее исправление: PPP328 (всего исправлений: 1)

Удалять файлы полнейшая глупость. И то, что им приходится патчить существующие программы тому ярчайшее подтверждение.

А в каких еще дистрах такое есть?

по таймеру по умолчанию

Мне одному кажется, что это противоречит сути /var/tmp?

как работает systemd

Аа... теперь понятно.

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

Где это написано? Стандарт говорит, что это надежное хранилище в контексте времени работы программы. Программа может работать хоть месяц, хоть год.

urxvt ★★★★★
()

Есть hier(7), но systemd тащит еще свой file-hierarchy(7).

Очередное подтверждение, что systemd это отдельная OC, почти как GNU, без ядра пока.

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

systemd есть встроенный бэкдор АНБ наравне с командой sudo…

А почему sudo бэкдор?

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

Ага, вот только тот же systemd срет туда данные своих сервисов.

Во-первых, не своих, а любых. Во-вторых, это не данные, а корни «виртуального /tmp» для PrivateTmp-юнитов.

В-третьих, для них уже сделано исключение: https://github.com/systemd/systemd/blob/main/tmpfiles.d/systemd-tmp.conf#L10-L18

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

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

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

Из !A -> !B не следует, что A -> B. Учим логику.

intelfx ★★★★★
()

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

@intelfx> для них уже сделано исключение: https://github.com/systemd/systemd/blob/main/tmpfiles.d/systemd-tmp.conf#L10-L18

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

Gentooshnik ★★★★★
()

Из этой новости я узнал, что них /tmp до сих пор не в tmpfs было по умолчанию.

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

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

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

Тут вопрос как раз к программам которые складывают в /tmp файлы которые должны быть «preserved between invocations of the program». Т.е. моё «соответствовать стандарту» - значит не складывать эти файлы ни в /tmp, ни в /var/tmp.

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

Насколько я могу судить, содержимое file-hierarchy(7) не противоречит содержимому hier(7) в части /tmp и /var/tmp. И периодическое удаление файлов не запрещено в hier(7) (ну и в https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index тоже).

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

Всё отлично соответствует всем стандартам.

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

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

atime

Пользователи SSD с noatime: «ну да, ну да, пошли мы нахрен».

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

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

Чтобы не было лишних ошибок, т. к. это точки монтирования и при попытке их удаления ты получишь EBUSY.

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

А, чёртов Русский Язык.

@Gentooshnik > Тут вопрос как раз к программам которые складывают в /tmp файлы которые должны быть «preserved between invocations of the program».

У программы есть файлы которые должны быть «preserved between invocations of the program». Программа зачем-то складывает их в /tmp хотя файлы там могут быть внезапно удалены.

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

Сам поймёшь, где обосрался, или тебе явно показать? :-)

@intelfx не может не думать о говне даже минуту.

Я прямо написал, что atime проверять плохая идея, потому что многие монтируют /tmp как диск, а не как tmpfs, и там atime будет выключен. У тебя, похоже, глаза твоей любимой субстанцией заплыли. Да, даже в Debian так делают.

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

Новость не читай сразу отвечай ;)

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

Хотя и не очень понятно, зачем это надо. У кого-то в /var/tmp так много хлама что ли? У меня просто…

sudo du -hs /var/tmp 
60K	/var/tmp
CrX ★★★★
()
Ответ на: комментарий от Gentooshnik

Извиняйте, прочитал по диагонали.

Если программа требует, чтобы файлы были preserved between invocations of the program — она не должна пользоваться {,/var}/tmp.

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

[1]: В стандарте в любом случае написано, что data stored in /tmp may be deleted in a site-specific manner.

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

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

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

intelfx не может не думать о говне даже минуту.

Не, я просто подстраиваюсь под уровень и лексикон собеседника.

Я прямо написал, что atime проверять плохая идея, потому что многие монтируют /tmp как диск, а не как tmpfs, и там atime будет выключен

Ну это их проблемы. Проверка atime в любом случае не является несущей конструкцией.

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

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

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

Но поскольку там atime берётся в рассчёт, это не проблема.

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

для них уже сделано исключение

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

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328
  1. покажи нарушение общепринятого стандарта
  2. исключение не для того, чтобы не сломать самого себя, а для того, чтобы не было лишних EBUSY
intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Не, я просто подстраиваюсь под уровень и лексикон собеседника.

Какого именно? Потому что о говне тут пишешь только ты.

Ну это их проблемы.

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

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

в контексте более чем одного запуска программы.

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

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

Какого именно?

Тебя.

Удаление файлов во время работы программы – крайне плохая идея.

Есть хотя бы один реальный пример такого удаления, которое что-то ломает? Потому что очистка старых файлов в /tmp по крону — практика, восходящая ещё к солярке.

В systemd по этому поводу даже больше предосторожностей, чем было исторически (проверка всех трёх временных отметок; flock).

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

Да, и ты должен быть к этому готов, потому что в FHS написано, что data stored in /tmp may be deleted in a site-specific manner. Если ты к этому не готов — не пользуйся /tmp.

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

[1]: В стандарте в любом случае написано, что data stored in /tmp may be deleted in a site-specific manner.

Ой,а не вы ли N минут назад мне скинули ссылку, где systemd для себя любимой делает исключение?

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

Это приведёт к тому, что разработчикам придётся искать новое место для хранения временных файлов со всеми вытекающими. Создали проблему на ровном месте.

u5er
()

Неужели это заслуживает новости, тем более не мини?..

ЕМНИП, раньше не переходили, т.к. всякие там Firefox любили складывать в /tmp скачиваемые файлы, которые тупо не поместятся в tmpfs, но вроде как большинство программ уже отучили.

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

Тебя.

Я тебе о говнах не пишу. У тебя точно глаза залепило.

Есть хотя бы один реальный пример такого удаления, которое что-то ломает?

Прямо в новости написано, что openssh и tmux пришлось патчить. Наверняка есть другой софт, который тоже надо патчить, но не запатчили.

Вообще, systemd любят ломать всё подряд. Вспомни хотя бы убийство фоновых tmux и screen при завершении сеанса юзера.

Потому что очистка старых файлов в /tmp по крону — практика, восходящая ещё к солярке.

И где сейчас эта солярка? Вот именно.

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

Если понимать буквально, это означает, что можно вообще прям при записи отправлять в /dev/null. А что, вполне site-specific manner. Только помимо стандартов есть всё же какой-то здравый смысл, и большинство программ не будет ожидать, что файл был удалён через секунду после создания, иначе любое использование /tmp полностью теряет свой смысл, кроме как для кэша (а для него вообще-то ~/.cache есть).

Но опять же, сабж — это адекватная реализация, поскольку новые файлы не удаляются, только старые.

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

Прямо в новости написано, что openssh и tmux пришлось патчить. Наверняка есть другой софт, который тоже надо патчить, но не запатчили.

Это не имеет никакого отношения к новости, т. к. в обоих случаях речь идёт о сокетах, которые в любом случае невалидны между перезапусками системы. А очистка /tmp по таймеру — практика, предшествующая И сабжевой новости, И даже systemd.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.