Безопасно ли делать `rm -rf /tmp/*` ?

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

Короче, важно понимать, что ты делаешь, когда и зачем. Девопсы это, скорее всего понимают (потому и делают), а ты (судя по этому вопросу) — не очень.

Мне не нравится, ищу аргументы

Охрененно. Просто охрененно.

Ну, например, «мне в детстве гадалка нагадала, что от очистки темпов в контейнере у меня отсохнет жопа» - нормальный аргумент при таком подходе.

Впрочем, могу дать тебе один аргумент, только он не от безопасности, а от чистоты, так сказать: если много что срёт ненужным хламом в /tmp и не подчищает потом за собой, от чего приходится его периодически сносить, то по-хорошему, в это что-то надо добавить собственно этап cleanup в конце, если это свой костыль. Если чужое, то можно обернуть в свой враппер. Это требует чуть больше усилий, да, но как результат, у тебя получаются инструменты, которые не зависят от такой вот чистки /tmp и не срут, где не надо. Плюс, если /tmp после вноса соответствующих изменений в систему A и систему Б, всё равно продолжает «засираться» неудаляемыми остатками, это неплохой способ это заметить и обнаружить, что срёт и нуждается в доработке инструмент В. Ну ты понял. Можешь с этой стороны попробовать аргументацию выстроить, если очень хочется. Хотя я бы советовал забить, «мне не нравится» — плохой повод изначально.

Я сейчас забью, а потом будут проблемы, когда буду подрываться на минах. Давайте так попробуем: есть ли правила поведения относительно /tmp? Я встречал такой паттерн, что файлы создаются в /tmp одной программой, потом имя файла передаётся в другую. Очевидно же, что файлы бывают закрытыми в какой-то момент и если их невовремя стереть - будут проблемы. ИИ заявляет, что если выполнить эту команду, может упасть X11. Но в контейнере его нет, поэтому это плохой аргумент для моего случая.

ИИ заявляет, что если выполнить эту команду, может упасть X11.

what

Вот что ещё пишет ИИ, и это выглядит серьёзно. Прикольно конечно, что на нормальный вопрос большинство отвечающих начало с того, что попыталось меня унизить :) Забыл, что кожаные мешки ещё и воняют, а пользы от них зачастую ещё меньше, чем от ИИ: они тоже могут не знать матчасть, но редко это признают, зато часто они даже не пытаются ответить на вопрос по существу.

2. Проблемы с сокетами (Unix domain sockets) Многие программы (например, базы данных, системные демоны, Docker, X-сервер) используют /tmp для создания временных сокетов для межпроцессного взаимодействия (IPC). Если вы удалите файл сокета, который активно используется, программа не пересоздаст его автоматически (или пересоздаст с другим именем). Это приведет к тому, что клиенты не смогут подключиться к сервису. Например, команды docker перестанут отвечать, если удалить сокет в /tmp, или зависнет графическая оболочка, если удалить сокет X11.

3. Проблема с блокировками (Lock-файлы) Многие программы создают в /tmp файлы блокировок (.lock или .pid), чтобы гарантировать, что одновременно запущен только один экземпляр процесса. Если удалить такой файл во время работы программы, программа может потерять контроль над блокировкой. Последствия: при попытке запустить второй экземпляр программы конфликта не произойдет (так как блокировка исчезла), и вы получите конфликт данных — два процесса начнут одновременно писать в один и тот же общий ресурс (файл базы данных или лог), что приведет к коррупции (повреждению) данных.

4. Проблема кэширования (Memory-Mapped Files) Некоторые тяжелые приложения (например, Java-машины или редакторы видео) отображают файлы из /tmp в свою виртуальную память (mmap). Если удалить такой файл, операционная система не освободит память мгновенно, но при попытке программы обратиться к определенной странице памяти возникнет ошибка SIGBUS (Bus error). Эта ошибка, как правило, приводит к аварийному завершению (Segmentation Fault) всего приложения с потерей несохраненных данных.

Вот бы узнать соответственно, правду ли тут пишет ИИ или это бред. Если хотя бы два пункта - правда, то я просто отклоню этот МР и пусть его кто-нибудь другой визирует.

Каком контейнере?

В докер-контейнере, если это важно.

правду ли тут пишет ИИ или это бред

Бредогенераторы (LLM, которые ты по ошибке называешь ИИ) всегда пишут бред (см. их название), но иногда этот бред случайно совпадает с действительностью. Анализировать бред - занятие непродуктивное, так что лучше прекращай это делать.

Родной, у тебя тут контейнеры. Оба приложения в него кладут девопсы. Оставь девопсам девопсово, пусть удаляют что хотят.

Докер-контейнеры по его традиционным правилам должны быть рассчитаны на то, что их вообще целиком снесут и запустят заново. И всё содержимое их внутренностей соответственно не сильно важно.

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

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

Кто? Где?

Тебе первым же ответом развёрнуто и по существу ответили. Ну следующий пост шуточный, обиделся чтоли?

Вот https://unix.stackexchange.com/questions/11235/is-it-safe-to-rm-rf-tmp - ответ от отборных кожаных мешков. В общем, если девопсы умные, а я лох, то пусть они сами себе свой МР и визируют. А я в этом ничего не понимаю, значит и визы не поставлю.

Всё зависит от конкретного случая. Но в общем случае (если нет конкретных аргументов «за») так делать и правда не стоит.

Мне дали ответ, но я спрашивал не совсем про то. Сборка - это простая часть. Сломаться может что-то другое в ОС и меня интересовало именно это в первую очередь. В любом случае, всем спасибо, ответ найден.

drwxrwxrwt 2 root root 40 Aug 18 00:02 .ICE-unix
drwxrwxrwt 2 root root 40 Aug 18 00:02 .X11-unix

не только X , но и Pulse

но в контейнере этого наверное нет

> есть ли правила поведения относительно /tmp

Формально — нет. По факту — POLA [1]. Нужно также учитывать, что никто не знает как обращаться с /tmp и никто, как следствие, не имеет формальных ожиданий.

Файлы из /tmp можно удалять только будучи уверенными, что это точно мусор.

[1]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment

я спрашивал не совсем про то.

В оп-посте у тебя инфы по минимуму, сорян. Спросил через жопу и сам же обиделся :)

По сабжу - я часто ковыряюсь в /tmp в «ручном» режиме - т.е. туда сбрасываю что-то, обрабатываю. Иногда массово удаляю, но чаще по маске расширения. Еще у меня настроена автозагрузка из браузера туда и если бывает забивается мусором могу и удалить вообще всё. Единственное удаляю конечно без sudo.

Брат жив, иксы не падали.

drwxrwxrwt 2 root root 40 Aug 18 00:02 .ICE-unix drwxrwxrwt 2 root root 40 Aug 18 00:02 .X11-unix

Чисто по приколу удалил - музяка играет, иксы иксят :)

> Девопсы это, скорее всего понимают (потому и делают)

В системе в будущем может что-нибудь поменяться относительно работы с /tmp. И это изменение не будет учитывать rm -fr /tmp/* (про него все забудут), который будет внезапно ломать какую-либо программу.

Давайте так попробуем: есть ли правила поведения относительно /tmp?

«Понимай, что ты делаешь, когда и зачем». Универсальное правило.

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

Но после неё запускается команда, за которую уже я отвечаю.

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

Я уже написал, что под этой строчкой не подпишусь. Как я уже написал, если кто-то компетентен, а я нет, то пусть этот кто-то и визирует. Я не знаю и знать не хочу, что в системе от этого сломается, но я зато знаю, что я с этим столкнусь и наступлю на грабли, тогда единственное, что могу сделать - это хотя бы отказаться их подкладывать. В наше время всё знать нельзя, «моя» команда не моя, моего в ней в лучшем случае 0.1%, и это так у всех, потому что все пользуются сложными программами и фреймворками. А удаление в /tmp повлияет на всю ОС, где вообще миллиард строк. Очевидно, знать это нельзя и не нужно. Просто нужно не трогать таким грубым образом, и всё.

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

Эти директории указанная команда не удалит.

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

В контейнере, где запущен один процесс, про который ты всё знаешь; или же если речь вообще о постройке образа, это может быть безопасно.

Если это просто чистка мусора, я бы использовал поиск файлов, к которым не было обращений больше недели, например, и удалял их. По сути это простой вызов find с определенными аргументами. Не намного сложней вызова rm. А шансов того, что какая-то программа создала файлы в /tmp, не обращалась к ним уже неделю, но при этом внезапно решит обратиться и сломается, кажется не очень много. Хотя всякое бывает…

C sudo удалил-то? В контейнере обычно команды от рута.

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

C sudo удалил-то?

Ну.. да, удалил же а не попытался :)

Информации достаточно, чтобы написать мне, что я лох, а вот девопсы молодцы.

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

Что само по себе как ситуация смешно и такие комментарии в твой адрес и вызывает :)

man mktemp(1). По идее, если софт должен что-то писать в /tmp, он должен сначала создать себе временный каталог, и уже в него пулять свои временные файлы. Тогда чистка проходит безболезненно для других программ.

Сокетам и блокировкам в /tmp делать нечего, для этого есть /var и /run.

уже запущенные приложения упасть не должны, а вот новые...
если только
1. X server не пересоздаст сокет
2. Если он вообще удалился..

Но после неё запускается команда, за которую уже я отвечаю.

Значит, ты должен сам знать, нужно ли тебе что-то из tmp или нет. Если не нужно, то в чем тогда проблема?

Я разве писал, что мне ИИ подсказал эту озабоченность? Опять же, выдумали что-то и начали пытаться меня гнобить. Только кожаные мешки так себя ведут. Я у ИИ только её начал проверять и в итоге нашёл, что на SO думают так же, как и я. Да и здесь большинство тоже пишет, что так делать нельзя. ИИ также мне даже предложил обходные пути для той причины, по которой девопсы так стали делать.

Не знаю, чему вас там в школе учили, но я свои 7 уже съел - у меня в /tmp полно файлов .lock, которые сделал точно не я и не мои кривые руки :)

При этом ты не столько хочешь разобраться, сколько по надуманной (нагугленной у «ии») причине хочешь всё запретить.

Моя задача - одобрить МР или не одобрить. Я вижу, что они делают не то. Я должен за них искать доказательства, что так делать можно? Если я под этим подпишусь, то я же потом и буду расхлёбывать, т.к. чинить упавшие сборки потом придётся в том числе и мне. Почему я должен хотеть разобраться? Моя задача не в том, чтобы во всём разобраться, а в том, чтобы сделать свой софт. Я вижу, что мне тут хотят грабли подложить. Мне достаточно сделать, чтобы грабель не было, а разбираться в конструкции грабель для этого не нужно.

ИИ заявляет, что если выполнить эту команду, может упасть X11.

Ты крутишь иксы в контейнере?

what

Только не говори, что ты ни разу не удалял иксовый сокет в /tmp ;)

Нет, потому-то этот аргумент и слабый. Хотя и такое тоже бывало.

Я удалял руками только срань от ImageMagick. Он иногда гигабайтные темпы создавал. Идиоты..

Внутри контейнера ты можешь запускать хоть rm -rf /. Что-то другое в ОС от этого не сломается.

Мне достаточно, чтобы в контейнере сломалось, потому что дальше идёт моя команда сборки, которая может сломаться совершенно неизвестным образом (потому что может сломаться что угодно в ОС, что я вызываю), а через неделю все забудут про это rm -rf. Грабли классические, первый сорт.

Есди в контейнер кто-то пробросил папку с X11-сокетом для гуя, то она как раз в /tmp и удаление может повлиять на хост.

Эмоции — это, конечно, следствие, а не причина. Но это автоматическое следствие, поэтому паттерн «чувствую, потом ищу источник чувств» вполне естественен, равно как и паттерн «чувствую, хоть и знаю, что не прав».

А ваша претенциозность, как обычно, безосновательна.

судя по фотографии

вы тригирнулись на симптомы

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

собственно вы на 99.(9)% уверены в дыреспособностей девопсов подручных вот и ужасает что их клавилификации хватить на бессознательную активацию пачта Бармина

- ну вам же за всерурочные ежель чё премируют! ведь же премируют?! !?

А при чем тут последняя команда? При чем тут МР? Или ты должен одобрить rm-rf /tmp/*? Если так - просто пиши «удаление всех файлов из временного каталога потенциально может вызвать проблемы и является плохой практикой. Правильное поведение - удаление временных файлов тем приложением, которое их создало. Измените команду таким образом, чтобы удалялись только артефакты сборки».

А вообще в этом проблема. Есть контейнер, в котором происходит сборка и он существует только в момент сборки (FROM AS BUILDER). В нем собирается приложение, а потом переносится уже в целевой контейнер. И это правильная практика. И ничего выносить из темпа не надо.

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

той причины, по которой девопсы так стали делать.

Озвучишь?)

Вот еще б ты упрекал кого-то в претенциозности ггг. Посмотри, кстати, значение этого слова в словаре.

Моя претензия в том, что «помогите обосновать запрет на основе моего неосознанного жопного дискомфорта» это не технический вопрос, а психиатрический. Нахера помогать васе вредить людям во имя его священных эмоций и за пределами его компетентности?

Только не говори, что ты ни разу не удалял иксовый сокет в /tmp ;)

Выше попробовал - не получилось. Видимо я настолько плох 🤣

Логика очень простая (всё ниженаписанное - моё ИМХО, разумеется).

Есть ЯП без сборщика мусора. Есть со сборщиком.

Твои девопсы не хотят руками следить за временными файлами внутри контейнера.

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