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

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

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

 [Timer]
 OnCalendar=daily
 Persisternt=true
 OnBootSec=15min

из Microsoft

Где? По ссылке этого слова не увидел.

По второй ссылке: @microsoft

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

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

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

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

Правильно.

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

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

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

Ага, вот только тот же 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а просто соответствовать стандарту

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

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

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

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

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

А что если

1. flock
2. atime

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

Никакой стандарт не говорит о том, что файлы должны быть preserved between invocations of the program. Отправляйся вслед за urxvt учить логику.

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

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

atime

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

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

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

Логику сейчас ты отправишься учить. Где я говорил что файлы должны быть preserved between invocations of the program?

Пользователи SSD с noatime

/tmp на tmpfs

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

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

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

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

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

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

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

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

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

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

sudo du -hs /var/tmp 
60K	/var/tmp

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

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

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

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

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

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

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

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

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

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

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

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

Это нигде не прописано

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

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

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

1. покажи нарушение общепринятого стандарта
2. исключение не для того, чтобы не сломать самого себя, а для того, чтобы не было лишних EBUSY

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

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

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

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

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

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

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

Тебя.

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

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

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

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

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

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

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

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

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

Если ты к этому не готов — не пользуйся /tmp.

https://github.com/systemd/systemd/blob/main/tmpfiles.d/systemd-tmp.conf#L10-L18

Ну дак может тогда отправите им ПР с вашей цитатой?

У тебя память как у золотой рыбки.

Тебя.

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

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

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

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

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

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

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

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

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

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