标签: tmp

在下面的链接文章中，他们解释了如何创建“chroot”/tmp 目录。我对他们的所作所为有点困惑。有人能解释一下以下命令的作用吗？

Noexec 和 /tmp 故障排除

1. # mkdir -p /root/chroot /root/tmp 
2. # mount --bind / /root/chroot 
3. # mount --bind /root/tmp /root/chroot/tmp
4. # chroot /root/chroot

在第一步中，为什么他们创建/root/tmp而不是/root/chroot/tmp？

第一个安装命令会影响第二个安装命令吗？第二步，他们将新目录/root/chroot绑定到根目录。这是否意味着第三步/root/tmp实际上指向/root/chroot/root/tmp？/root/chroot/tmp从哪里来？这就是我感到困惑的部分。

这背后的逻辑是什么？

我/只剩下大约 800MB 的可用空间。我想这就是原因

$ convert * book.pdf
Segmentation fault (core dumped)
bash: cannot create temp file for here-document: No space left on device

我认为convert（来自 Imagick）用于/tmp存储临时文件。当前目录下的文件为188个png，jpg文件总数约70MB。为什么 800MB 可用空间\不能满足convert？

我可以绕过限制空间/吗？我还有更多的空间~和其他分区，而且我还有外部 USB 存储设备。谢谢。

假设我正在运行一些冗长的过程，包括两个步骤：a生成一个大的中间文件，例如/tmp/aoutput，然后b读取该文件并对其执行进一步的操作。

现在系统在执行该b步骤时崩溃了。是否可以以一种不会像启动时通常发生的那样删除 的内容的方式重新启动系统/tmp，以便我们可以立即重新启动b而无需先a完全运行？

这当然假设/tmp没有安装在tmpfs.

我想排除涉及物理取出 HDD/SSD 或使用实时 USB 介质启动的解决方案。在我现在的具体情况中，它实际上是一个具有全盘加密的 SSD，但我也对仅适用于非加密驱动器的解决方案感兴趣。

编辑现在仍然保留这个问题，因为这两个答案都没有提供一个无需实时媒体或事先调整配置即可工作的解决方案。也许确实不可能有其他方式，但看起来很奇怪：GRUB 不是已经挂载分区来引导 Linux 了吗？如果是这样，是否有办法在启动之前手动移动文件systemd？也许我错了，我对引导加载程序知之甚少；但我想听听为什么这是不可能的。

systemd配置信息：

$ grep -s . /*/tmpfiles.d/*.conf /*/*/tmpfiles.d/*.conf
/run/tmpfiles.d/kmod.conf:c! /dev/fuse 0600 - - - 10:229
/run/tmpfiles.d/kmod.conf:c! /dev/cuse 0600 - - - 10:203
/run/tmpfiles.d/kmod.conf:c! /dev/btrfs-control 0600 - - - 10:234
/run/tmpfiles.d/kmod.conf:d /dev/net 0755 - - -
/run/tmpfiles.d/kmod.conf:c! /dev/net/tun 0600 - - - …

我尝试按照https://docs.docker.com/engine/security/rootless/中的说明运行脚本：

$ curl -fsSL https://get.docker.com/rootless | sh

但脚本在以下行中崩溃了：

curl -L -o docker.tgz "$STATIC_RELEASE_URL"

随着消息：

Warning: Failed to create the file docker.tgz: Permission denied
curl: (23) Failure writing output to destination

我将问题范围缩小到curl尝试写入tmp由 创建的文件夹mktemp -d，但我不明白为什么它失败。

一些背景：

$ whoami
thiago

$ uname -a
Linux thiago-acer 5.8.0-55-generic #62~20.04.1-Ubuntu SMP Wed Jun 2 08:55:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ mktemp -d
/tmp/tmp.U1nPTN5dlS

$ cd /tmp/tmp.U1nPTN5dlS

$ ls -la
total 8
drwx------  2 thiago thiago 4096 Jun …

我想创建一个只能由创建它的进程（及其子进程）访问的文件，并且当进程退出时该文件就会消失，理想情况下永远不会将文件持久保存到磁盘。举个例子，我想创建/mylocation/myfile.txt，其中该文件只能从当前进程读取，而不能从任何其他进程读取，甚至不能从同一用户读取。我很高兴使用除 之外的一些神奇位置/mylocation，例如 下的某处/prod/PID，但它需要适用于任何文件名。

背景是我正在使用一个现有的库，它从$FOO/mypassword. 多个进程在同一用户帐户下运行，但具有不同的秘密密码。我希望从其他进程安全地将密码传达给图书馆。我很欣赏理想的解决方案是使用不同的用户帐户或让库不从文件中读取密码，但我无法控制这些方面。

从启用了 SUID 位 (chmod +s) 的可执行文件打印 getuid() 和 geteuid() 的值，如果该可执行文件位于 /tmp 目录中，则结果似乎是原始调用者 ID 而不是所有者 ID .

将完全相同的代码编译到主目录（并执行 chmod +s）时，这似乎按预期工作。

我搜索了很多，找不到任何关于这种行为的参考。

有人知道为什么会这样吗？

这个来源很简单：

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main(){
    printf("%d\n%d\n", getuid(), geteuid());
    return 0;
}

我想调查 /tmp 中的文件何时被删除。我运行 CentOS 7。有关从该目录中删除文件的政策管理如下：

RHEL7 和 RedHat-like with systemd 它在 /usr/lib/tmpfiles.d/tmp.conf 中配置，由 systemd-tmpfiles-clean.service 调用）

我猜三年前的文件已经够旧了，可以删除。所以我这样设置访问时间

find  /tmp/payaramicro*tmp -exec touch -m -a -t 201512180130.09 {} \;

但是，当我运行时，systemd-tmpfiles --clean这些文件不会被删除。为什么？也许它与他们的日期有关，因为stat some-file在输出的其中一行中显示了今天的日期：

访问：2015-12-18 01:30:09.000000000 +0100 修改：2015-12-18 01:30:09.000000000 +0100 更改：2018-04-18 12:20:904.

在我所有的 Red Hat Linux 机器版本 7.2 上，我们看到 systemd-tmpfiles-clean.service 处于非活动状态：

systemctl status systemd-tmpfiles-clean.service
? systemd-tmpfiles-clean.service - Cleanup of Temporary Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static; vendor preset: disabled)
   Active: inactive (dead) since Wed 2018-12-19 14:47:14 UTC; 12min ago
     Docs: man:tmpfiles.d(5)
           man:systemd-tmpfiles(8)
  Process: 34231 ExecStart=/usr/bin/systemd-tmpfiles --clean (code=exited, status=0/SUCCESS)
 Main PID: 34231 (code=exited, status=0/SUCCESS)

Dec 19 14:47:14 master02.uridns.com systemd[1]: Starting Cleanup of Temporary Directories...
Dec 19 14:47:14 master02.uridns.com systemd[1]: Started Cleanup of Temporary Directories.

奇怪的是，我们看到了下面的文件和文件夹/tmp，似乎每隔一段时间就进行一次清理。

我搜索了 crontab 或 cronjob，但没有找到其他清理工作。

我在这里错过了什么吗？

尽管服务处于非活动状态，但是否有可能每两周执行一次清理？

  systemctl …

我在一台系统驱动器有限的机器上使用 Ubuntu 20.04。

我遇到了一个构建脚本，用于检查 中的可用大小/tmp，如果它没有看到 12 GB 可用空间（我的系统驱动器上没有该空间），它就会拒绝运行。

不过，我的这台机器上确实有另一个 NTFS 驱动器；由于它是NTFS，我不能真正直接使用它，但我可以创建一个磁盘映像。

因此，我想到在 NTFS 分区上创建一个 16 GB 的 ext3 映像，然后将其挂载为 /tmp。

所以，我尝试过：

dd if=/dev/zero of=tmp16.img bs=16M count=0 seek=1024
mkfs.ext3 ./tmp16.img
fdisk -l ./tmp16.img
e2label ./tmp16.img tmp16

到目前为止，一切都很好——所有这些都有效；但后来我尝试安装：

$ sudo mount -o remount /path/to/ntfs/tmp16.img /tmp
mount: /tmp: mount point not mounted or bad option.

Ups，一定是我在某个地方的旧记忆，那/tmp是一个单独的安装 - 事实证明，在这台机器上，/tmp不是一个单独的安装：

$ mount | grep tmp
udev on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=3970256k,nr_inodes=992564,mode=755)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=802768k,mode=755)
tmpfs on …

我有一个通过 SSH 连接到远程主机的脚本，创建临时文件并执行以下命令：

调用系统(mysql --database=information_schema --host=localhost < /tmp/drush_1JAjtt)

每次它创建不同的文件（模式：）drush_xxxxxx。

我已经尝试在远程手动运行几次：

tail -f /tmp/drush_*

但我的连接速度太慢，大多数时候我都会遇到错误：

tail：无法打开`/tmp/drush_*'进行读取：没有这样的文件或目录

有什么技巧可以在创建此类文件后立即访问该文件以显示其内容吗？