Временная папка tmp Linux
В какой переменной окружения Linux хранит путь к папке temp\tmp? Мне нужно программно найти путь к этой папке. Программа на C++.
Отслеживать
задан 9 ноя 2016 в 12:38
253 4 4 серебряных знака 15 15 бронзовых знаков
Не факт что вообще в какой-то. У меня, например, под Mint и Debian такой переменной нет.
9 ноя 2016 в 12:41
Уточните, вам нужно именно узнать путь к папке temp в системе (в таком случае, вам нужно указать, по каким критериям искать — например, эта папка должна быть указана в какой-то переменной), или программно создать временный файл в папке, предназначенной для временных файлов, и в которой этот файл гарантированно создастся? ИМХО, от этого будет зависеть, какой ответ получите.
9 ноя 2016 в 13:02
если память не изменяет то команда set вам все покажет
9 ноя 2016 в 14:05
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
согласно стандарту posix каталогом для хранения временных файлов является каталог /tmp .
но, т.к. вы спрашиваете конкретно про операционную систему gnu/linux, то здесь применим стандарт fhs, согласно которому местом для сохранения временных файлов является не только каталог /tmp , но и каталог /var/tmp . разница между ними в том, что первый обычно (но не обязательно) очищается при загрузке операционной системы.
а т.к. вы уточняете ещё и про c++, то вышеописанной информацией можно пренебречь ввиду наличия определённой стандартом posix функции tmpfile() и её c++-аналога std::tmpfile().
наличие же каких-либо переменных окружения, связанных с каталогом для хранения временных файлов, насколько мне известно, ни одним из упомянутых стандартов не требуется.
Всё, что вам нужно знать о каталоге /tmp в Linux
Я понял, что не уделял должного внимания каталогу /tmp или /var/tmp , пока не прочитал статью, которую увидел в Интернете. Поэтому я подготовил эту статью, надеюсь она будет полезной.
Что такое каталог Linux /tmp?

В системах на базе Linux каталог /tmp — это каталог, в котором хранятся временные файлы необходимые для запущенного программного обеспечения и приложений работающих в системе. Например, при написании документа все содержимое документа сохраняется как временный файл в каталоге /tmp . Временный файл удаляется при выходе.
В чем разница между каталогом /tmp и каталогом /var/tmp?
Обычно и /tmp , и /var/tmp используются для временного хранения данных. Однако основное различие между ними заключается в том, как долго данные хранятся в этих файловых системах. Срок хранения данных для /var/tmp намного больше, чем для /tmp .
По умолчанию все файлы и данные хранящиеся в каталоге /var/tmp хранятся до 30 дней. Данные в /tmp автоматически удаляются через десять дней (пока система перезагружается).
Кроме того, временные файлы хранящиеся в каталоге /tmp удаляются сразу после перезагрузки системы, поэтому каталог /var/tmp используется программами для временного хранения данных, которые необходимо сохранять между перезагрузками.
Может ли каталог /tmp заполниться?
Файлы и данные хранящиеся в каталоге /tmp имеют размер всего несколько КБ. Так что заполнение каталога /tmp возможно, но сложно.
В среднем системе для заполнения каталога /tmp в нём должны быть миллионы временных файлов. Не о чем беспокоиться в домашней системе, которая часто выключается, поскольку при перезагрузке удаляются все файлы хранящиеся в каталоге /tmp .
Однако если вы системный администратор у которого сервер редко перезагружается и обслуживает тысячи пользователей, заполнение каталога /tmp может быть проблемой. По мере накопления в каталоге временных файлов постепенно угрожает всему пространству хранения, что может быть тревожной новостью.
Как удалить файлы хранящиеся в каталоге /tmp?
Не рекомендуется удалять файлы в каталоге /tmp , если вы не уверены, что делаете. Они важны и необходимы для программного обеспечения работающего в вашей системе. Их удаление может привести к сбою системы. Вам не нужно сильно беспокоиться, так как файлы и данные хранящиеся в каталоге /tmp автоматически удаляются при перезагрузке системы.
Однако для серверов, которые работают в течение нескольких месяцев важно время от времени очищать каталог /tmp , прежде чем каталог переполнится.
Я случайно удалил каталог /tmp, что мне теперь делать?
При удалении файлов /tmp вручную, некоторые пользователи также случайно удаляют каталог /tmp . В таком случае вы можете быстро восстановить удаленный каталог /tmp .
Все, что вам нужно сделать, это ввести следующие команды в свой терминал:
$ sudo mkdir /tmp
$ sudo chmod 1777 /tmp
Первая строка создает новый каталог /tmp . Вторая строка позволяет всем пользователям читать, записывать и выполнять файлы в каталоге /tmp .
Убедившись, что все в порядке необходимо перезагрузить систему. Это позволит программам начать использовать только что созданный каталог /tmp .
Что представляет из себя директория /proc, /tmp?
1) Если /proc не хранит информация не на диске, не в рам — то где вообще? Не понимаю(
2) Например я в bash. Возможно ли как-то получить мой вывод, смотря в папку /proc процесса bash?
3) Если папка /tmp хранится в ОЗУ, могу ли я там хранить свои временные файлы для мгновенного доступа?
4) Как можно реализовать подобное: Есть файл, в который постоянно пишется информация, чтобы он не занимал много места, я ставлю условный лимит в 10000кб, когда файл начинает весить больше, то разница будет стёрта из начала файла. Например файл (огр. в 10байт): f.test
1234567890
Я например в него пишу echo 10 >> f.test,
теперь в файле:
3456789010
Такое возможно реализовать, без крон задач?
Подскажите, просто интересно))
- Вопрос задан более трёх лет назад
- 2180 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 4
Saboteur @saboteur_kiev Куратор тега Linux
software engineer
1) Если /proc не хранит информация не на диске, не в рам — то где вообще? Не понимаю(
/proc это вообще абстракция. Ядро системы знает какие процессы сейчас запущены и хранит это в памяти. А в /proc визуализирует это, предоставляя некий интерфейс в виде «все есть файл». Просто нужно понимать, что это не ext2/ext3/ext4 эмулируемый в памяти, это именно procfs
2) Например я в bash. Возможно ли как-то получить мой вывод, смотря в папку /proc процесса bash?
да, можете подключиться к вашему stdout, который собственно /proc//fd/1
можно посмотреть как вы подключились и куда смотрит ваш /proc//fd/1 (скорее всего в какой-нить /dev/pts/0) и оттуда тоже смотреть.
3) Если папка /tmp хранится в ОЗУ, могу ли я там хранить свои временные файлы для мгновенного доступа?
Да. Только нужно помнить, что tmpfs не ограничен, то есть чем больше туда кладешь, тем меньше свободного ОЗУ остается
4) Как можно реализовать подобное: Есть файл, в который постоянно пишется информация, чтобы он не занимал много места, я ставлю условный лимит в 10000кб, когда файл начинает весить больше, то разница будет стёрта из начала файла.
Нужно понимать, что стереть 10 байт из начала файла нельзя, потому что нужно сдвинуть содержимое всего файла. Другими словами — файл целиком придется перезаписать.
Поэтому применяют другой способ — log rotate — когда идет запись в файл, проверяется его размер. Если он превысил значение, файл переименовывается (например в file.log.1) и открывается новый файл file.log
Можно контролировать сколько файлов может быть в списке и не забывать переименовываьт все файлы, чтобы они соответствовали порядку. Но этим нужно заниматься тому, кто пишет в файл.
Ответ написан более трёх лет назад
Нравится 2 9 комментариев
нужно помнить, что tmpfs не ограничен
Mount options for tmpfs size=nbytes Override default maximum size of the filesystem. The size is given in bytes, and rounded up to entire pages. The default is half of the memory. The size parameter also accepts a suffix % to limit this tmpfs instance to that percentage of your physical RAM: the default, when neither size nor nr_blocks is specified, is size=50%
Нужно понимать, что стереть 10 байт из начала файла нельзя, потому что нужно сдвинуть содержимое всего файла.
Можно освободить место в начале, например вызвая fallocate с флагом FALLOC_FL_PUNCH_HOLE, но для этого нужна поддержка со стороны файловой системы.
Saboteur @saboteur_kiev Куратор тега Linux
jcmvbkbc, Как я вижу, «The FALLOC_FL_PUNCH_HOLE flag must be ORed with FALLOC_FL_KEEP_SIZE», то есть размер файла не должен изменяться, что противоречит тому, что файл уменьшился на удаленные с его начала несколько байт.
что противоречит тому, что файл уменьшился на удаленные с его начала несколько байт
Saboteur, не, это тупиковый вариант по многим причинам. Я предлагаю логический размер файла не уменьшать, всё время дописывать в конец, но постепенно удалять данные в начале файла, так, чтобы на диске оставался только условный лимит в конце.
Saboteur @saboteur_kiev Куратор тега Linux
А как это возможно?
Если мы запускаем fallocate без изменения размера файла, то что выходит? Файл не уменьшается, просто обнуляем данные в его начале.
Затем дописываем в конец новые данные, и вообще получается какая-то фигня.
Мы же не можем дописывать данные в конец и удалять в начале одной командой.?
Fallocate с дыркой вообще делает непонятную для меня вещь.
Если мы запускаем fallocate без изменения размера файла, то что выходит? Файл не уменьшается, просто обнуляем данные в его начале.
Мы же не можем дописывать данные в конец и удалять в начале одной командой.?
Не можем, но этого не требуется. Требуется иметь валидный хвост заданного размера — такой подход может это обеспечить.
Fallocate с дыркой вообще делает непонятную для меня вещь.
Он виртуально зануляет данные и физически освобождает занятое место. См. sparse file.. Из дырки читаются нули. Если начать туда писать — выделится физическое пространство. Что-то такое:
$ dd of=sparse bs=1G count=0 seek=1024 0+0 records in 0+0 records out 0 bytes copied, 6.9401e-05 s, 0.0 kB/s $ stat sparse File: sparse Size: 1099511627776 Blocks: 0 IO Block: 4096 regular file Device: fe03h/65027d Inode: 22684238 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/jcmvbkbc) Gid: ( 1000/jcmvbkbc) Access: 2019-08-18 15:42:04.772367087 -0700 Modify: 2019-08-18 15:42:04.776367113 -0700 Change: 2019-08-18 15:42:04.776367113 -0700 Birth: - $ echo test >> sparse $ tail -c 100 sparse | hexdump -Cv 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |. | 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |. | 00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |. | 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |. | 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |. | 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 74 |. t| 00000060 65 73 74 0a |est.| 00000064 $ stat sparse File: sparse Size: 1099511627781 Blocks: 8 IO Block: 4096 regular file Device: fe03h/65027d Inode: 22684238 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/jcmvbkbc) Gid: ( 1000/jcmvbkbc) Access: 2019-08-18 15:43:25.668878335 -0700 Modify: 2019-08-18 15:43:14.808809836 -0700 Change: 2019-08-18 15:43:14.808809836 -0700 Birth: -
Т.е. получился файл с размером в терабайт, занимающий на диске 8 блоков по 4К.
Saboteur @saboteur_kiev Куратор тега Linux
jcmvbkbc, Из дырки читаются нули
Но ведь это не есть то, что нужно — удаление вначале файла.
Если я попытаюсь прочитаьт этот файл построчно, сделать cat, я грубо говоря увижу эти нули, пусть они и непечатаемые.
То есть очень грязный хак.
Если я попытаюсь прочитаьт этот файл построчно, сделать cat, я грубо говоря увижу эти нули, пусть они и непечатаемые.
Saboteur, так не надо делать cat, надо делать tail
Saboteur @saboteur_kiev Куратор тега Linux
Понял. Имеет смысл для неструктурированных данных.
tmpfs обычно хранится в оперативке, но при нехватке памяти может свопиться на диск. Главное её свойство — это отсутствие транзакционных методов работы, необходимых нормальной файловой системе — это даёт скорость, а надёжность там не нужна, ибо при ребуте она чистится.
Хранить там свои файлы — можно и нужно. Но надо помнить: «при ребуте она чистится».
procfs не хранится нигде, а генерится на лету. Поясняю очень приблизительно:
Когда команда ls смотрит обычную файловую систему (обращается в директории, которую обслуживает обычная файловая система), то драйвер файловой системы читает некое хранилище — обычно HDD/SSD. И там лежат имена файлов — их можно найти программой типа diskedit (если Вы заете, что это такое).
Когда команда ls смотрит корень procfs — то драйвер procfs не читает никаких носителей, а запускает внутри себя команду ps (любители корректных формулировок сейчас закидают меня тапками). ps читает список запущенных процессов (который, вообще-то, хранится в памяти — в данных ядра) и передаёт его драйверу procfs. А драйвер procfs на основе этой информации формирует список номеров процессов.
Если команда ls смотрит в поддиректорию procfs — то драйвер procfs берёт информацию из данных ядра конкретно про этот процесс; эта информация тоже лежит в памяти, тоже в данных ядра.
Собственно, разница в том, что драйвер обычной файловой системы читает данные как они лежат — потому делает это строго в монопольном режиме, никто другое не имеет права их трогать. А драйвер procfs работает с данными, которые ядро в любой момент может поменять — и потому не читает их из места хранения, а запрашивает через «кладовщика» — через того же, через кого эти данные запрашивает программа ps и её «родственники».
А есть ещё одна интересная файловая система: devfs для директории /dev .
Планирование диска
На жёстком диске любого компьютера хранятся данные, которые используются совершенно по-разному. Одни составляют операционную систему или нужны ей для работы, другие нужны пользователю, он их создаёт сам или откуда-то получает. Некоторые данные нужны временно, например, только на время работы программы, другие предназначены для «вечного» хранения. Есть такие данные, которые может изменить только человек, и такие, которые система сама создаёт или модифицирует в процессе работы. Наконец, есть такие данные, которые могут храниться на одном компьютере, а использоваться на нескольких (например, по локальной сети), и такие, которые предназначены только для данного компьютера.
Надёжность хранения данных и эффективность доступа к ним возрастает, если разделять данные разных типов (различающиеся по характеру использования). Для этого всё доступное пространство на жёстком диске (или дисках) разделяется на независимые области, каждая из которых предназначена для данных определённого типа. Для организации таких областей хорошо подходит технология разделения диска на разделы.
Поскольку разделы не зависят друг от друга, изменение содержимого одного раздела никак не сказывается на других. Одна из выгод такого подхода: в случае физического сбоя повреждения данных будут локализованы внутри того раздела, где произошёл сбой, и не затронут других разделов. Разделы открывают также путь для оптимизации скорости доступа: скорость чтения и записи для большинства дисков выше в середине и ниже к концу и началу диска. В самой быстрой области можно расположить раздел с данными, для которых важна скорость доступа.
Разделение диска на разделы необходимо в том случае, если на одном физическом устройстве должны быть установлены несколько операционных систем. Каждой операционной системе потребуется выделить не менее одного раздела.
Необходимые разделы
Минимальное количество разделов, которые необходимы Linux для работы — два. Первый — для корневой файловой системы, второй — для области подкачки.
Область подкачки (swap space) — это пространство на диске, используемое системой для организации виртуальной памяти. Если какая-то область оперативной памяти долгое время не используется, её содержимое записывается на диск, в область подкачки — тем самым освобождается место в физической памяти для других процессов. Когда же эта область памяти потребуется вновь, ядро подкачает её с диска и разместит в оперативной памяти.
Благодаря этому вполне может сложиться ситуация, когда используется больше оперативной памяти, чем её есть в действительности: если не вся заказанная память используется одновременно, что позволяет системе откачивать некоторые области. В Linux принято размещать область подкачки на отдельном разделе, что позволяет увеличить скорость доступа к данным и уменьшить риск повреждения ценных данных на основных разделах.
Для обеспечения максимальной скорости доступа к данным области подкачки ее раздел рекомендуется размещать в начале либо в середине диска. Данные, находящиеся в swap, являются временными и не представляют ценности после перезагрузки компьютера. Поэтому размещение swap-раздела, как и других разделов с неуникальными данными (например, /tmp и /usr — о них расказано ниже), в начале диска предпочтительнее: снижается риск потери важных данных.
Начало диска более подвержено повреждениям в том числе и из-за человеческого фактора. Печально известным примером опечатки, которая ведет к уничтожению данных в начале диска, может послужить dd of=/dev/hda вместо dd of=/dev/hda3 . Однако если в начале диска хранятся неуникальные данные, то этот процесс, будучи вовремя остановленным, не успеет добраться до действительно ценной информации в разделах /etc , /home или /var , в то время как восстановление таблицы разделов — задача несложная.
С корневой файловой системы начинает расти всё дерево файлов Linux. Точкой монтирования для корневой файловой системы служит “ / ” — корневой каталог. Можно поместить все данные (включая пользовательские файлы) на один раздел — это как раз тот случай, когда для Linux потребуется всего два раздела. Для повышения эффективности и надёжности некоторые ветви дерева файлов можно выносить на другие разделы. Поскольку для файловой системы Linux не важно, каким образом части дерева каталогов расположены на разделах дисков, у вас есть возможность использовать каждый из имеющихся разделов диска под любой каталог файловой системы. В этом случае раздел с корневым каталогом будет служить точкой монтирования для остальных файловых систем.
Смонтированной файловой системе важно указать правильные параметры монтирования. Задавая разделам с разными типами данных походящие параметры, можно добиться значительного повышения производительности и безопаснсти. Ниже перечислены наиболее часто используемые общие параметры монтирования.
noatime При каждом доступе к файлу, в том числе при чтении, обновляется время последнего доступа к нему. При использлвании этого параметра это обновление производиться не будет, что может быть полезно для ускорения работы (особенно актуально для серверов). nodev Этот параметр не позволяет создавать на файловой системе файлы-устройства. Если точно известно, что на данной файовой системе файлы-устройства не нужны, можно использовать этот параметр для повышения безопасности. nosuid Параметр запрещает исполнение SUID-программ. noexec Запрещает запуск исполняемых программ из файлов на данной файловой системе. ro Обеспечивает доступ к файловой системе только для чтения.
Дополнительно выделяемые разделы
/home Домашние каталоги пользователей. Здесь хранятся персональные каталоги всех пользователей машины. Размер каталога зависит от количества работающих пользователей и от их потребностей. Рекомендуемые файловые системы — Ext3 или XFS. Параметры — noexec (в случае невозможности применения — nosuid ). /usr Статические данные: большая часть пакетов устанавливает свои исполняемые файлы и данные в каталог /usr . Преимуществом размещения этого каталога в отдельном разделе является то, что при нормальной работе (кроме установки/удаления пакетов) не требуется в него записывать никаких данных, поэтому этот раздел можно монтировать в режиме «только чтение», в том числе по локальной сети. В этом случае несколько машин могут пользоваться одним сетевым разделом /usr . Размер этого раздела зависит от количества пакетов, которые будут установлены, он колеблется в пределах от 500 Мб для маленькой установки до нескольких гигабайт для полной установки. Вариант на 2–3 Гб (в зависимости от размера диска) скорее всего подойдёт. /var Переменные данные, которые создаются системой в процессе работы. Запись в этот каталог осуществляется весьма часто, а количество данных в нём имеет тенденцию расти (здесь расположены все системные журналы). Требования к объёму очень сильно зависят от профиля машины. На пользовательских домашних станциях будет вполне достаточно нескольких сотен мегабайт. Для серверов эта цифра будет существенно больше, поэтому для повышения производительности и надежности хранения информации переменные данные разных типов рекомендуеся располагать на разных разделах. Файловая система этого раздела должна поддерживать журналирование (Ext3). При монтировании желательно задать параметры noexec и nosuid . /var/log При установке на сервер лучшим решением будет вынести системные журналы на отдельный раздел. При сбоях или внешних атаках размер журналов может резко увеличиваться, что, в случае их хранения вместе с другими переменными системными данными, чревато сбоем в работе системы. Также, если сервер используется для выполнения узкого круга задач (например, как web-сервер), рекомендуется выносить на отдельный раздел журналы основной системной службы (например, /var/log/apache ). Оптимальная файловая система — Ext3, параметры — noatime , noexec , nosuid . /var/tmp Может быть полезным создать отдельную файловую систему для временных данных, которые нежелательно потерять в случае программного или аппаратного сбоя. Этот раздел должен обеспечивать высокую надежность хранения данных, поэтому оптимально создать в нем файловую систему с поддержкой журнализации (Ext3), указав параметры noexec и nodev . /var/spool/mail Если на сервере хранится почта пользователей, каталог с ней необходимо выделить в отдельный раздел. Также обязательно устаналивать ограничения на использование дискового пространства для отдельных пользователей, чтобы избежать неожиданного переполнения раздела и проблем с работоспособностью сервера. /var/www Раздел для сайтов пользователей. /tmp Этот каталог предназначен для временных файлов: в таких файлах программы хранят промежуточные данные, необходимые для работы. После завершения работы программы временные файлы теряют смысл и должны быть удалены. Обычно каталог /tmp очищается при каждой загрузке системы. Поскольку запись в этот каталог осуществляется очень часто, а требования к надёжности очень низкие, то есть большой смысл выделить /tmp в отдельный раздел. В противном случае он окажется частью раздела “ / ”, требования к которому по записи и надёжности прямо противоположные (см. ниже). Размер раздела /tmp в обычном случае должен быть примерно равен размеру swap . В последнее время раздел /tmp зачастую размещают в виртуальной файловой системе tmpfs непосредственно в оперативной памяти. / Корневой раздел — это самый важный раздел. Он не только содержит наиболее важные данные и программы системы, но будет также служить точкой монтирования для других разделов. Если /usr , /var и /home вынесены на отдельные разделы, то потребность в объёме корневого раздела небольшая, обычно достаточно 500 Мб. Требования: корневой раздел должен быть доступен в процессе загрузки, в процессе работы доступ на запись в этот раздел требуется нечасто, но весьма важна надёжность. /boot Небольшой раздел (5–10 Мб), на котром хранятся исполняемые и failsafe ядра и данные используемого загрузчика. Обычно располагается в самом начале жесткого диска и всегда является первичным разделом (в отличие от логических томов в случае использования LVM). Оптимальная файловая система — Ext2, поскольку запись в раздел производится редко, а его объем мал.
Выделение вышеперечисленных разделов направлено прежде всего на повышение эффективности работы сервера. Для домашних рабочих станций чаще всего вполне достаточно, помимо необходимых разделов, выделить всго один — для хранения пользовательских данных ( /home ). Увеличения гибкости управления разделами, особенно при большом их количестве, можно добиться использованием технологии LVM, которая позволяет создавать, удалять и изменять размер логических устройств без риска потери данных.