侧边栏壁纸
博主头像
landery博主等级

行李箱里装不下我想去的远方

  • 累计撰写 45 篇文章
  • 累计创建 26 个标签
  • 累计收到 6 条评论

目 录CONTENT

文章目录

操作系统_04_IMA临时文件产生原因

landery
2022-04-18 / 0 评论 / 0 点赞 / 92 阅读 / 5,369 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-05-05,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。

操作系统_04_IMA临时文件产生原因

1 目前发现的临时文件

  1. /tmp
  2. /var/cache
  3. /sys/fs/cgroup/systemd/user.slice/user-0.slice/

2 /tmp原因

CentOS7下,系统使用systemd管理易变与临时文件,与之相关的系统服务有3个:

systemd-tmpfiles-setup.service :Create Volatile Files and Directories

systemd-tmpfiles-setup-dev.service:Create static device nodes in /dev

systemd-tmpfiles-clean.service :Cleanup of Temporary Directories

相关的配置文件也有3个地方:

/etc/tmpfiles.d/*.conf

/run/tmpfiles.d/*.conf

/usr/lib/tmpfiles.d/*.conf

/tmp目录的清理规则主要取决于/usr/lib/tmpfiles.d/tmp.conf文件的设定,默认的配置内容为:

# This file is part of systemd.
v /tmp 1777 root root 10d # 清理/tmp下10天前的目录和文件
v /var/tmp 1777 root root 30d # 清理/var/tmp下30天前的目录和文件
# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp

3 /var/cache原因

/var/cache 目的:存放应用程序的缓存数据,保存在该目录中的数据应用程序可以再生成,所以该目录中的数据丢失后不会影响系统。

4 /sys/fs/cgroup/systemd/user.slice/user-0.slice/原因

临时性文件:
1650017797488.png

原因总结:因为每个用户登录时会产生session,例如当我们使用MobaXterm通过三个ssh窗口登录时,它会产生6个session:

image.png

1650018154374.png

1650018214992.png

其中一个窗口打开两个session,一个是sshd启动的用户进程,一个是xftpserver。

当我们关闭一个窗口时,就会产生两个临时文件。

5 后续资料

systemd:

Systemd 是一系列工具的集合,其作用也远远不仅是启动操作系统,它还接管了后台服务、结束、状态查询,以及日志归档、设备管理、电源管理、定时任务等许多职责,并支持通过特定事件(如插入特定 USB 设备)和特定端口数据触发的 On-demand(按需)任务。

Systemd 的后台服务还有一个特殊的身份——它是系统中 PID 值为 1 的进程。

Systemd 可以管理所有系统资源,不同的资源统称为 Unit(单位)。

cgroup:

Linux系统中经常有个需求就是希望能限制某个或者某些进程的分配资源。也就是能完成一组容器的概念,在这个容器中,有分配好的特定比例的cpu时间,IO时间,可用内存大小等。于是就出现了cgroup的概念,cgroup就是controller group,可用来限制、记录、隔离进程组的物理资源,最初由google的工程师提出,后来被整合进Linux内核中。

systemd 默认挂载的 cgroups 系统

在系统的开机阶段,systemd 会把支持的 controllers (subsystem 子系统)挂载到默认的 /sys/fs/cgroup/ 目录下面:

1650017524318.png

除了 systemd 目录外,其它目录都是对应的 subsystem。
/sys/fs/cgroup/systemd 目录是 systemd 维护的自己使用的非 subsystem 的 cgroups 层级结构。这玩意儿是 systemd 自己使用的,换句话说就是,并不允许其它的程序动这个目录下的内容。其实 /sys/fs/cgroup/systemd 目录对应的 cgroups 层级结构就是 systemd 用来使用 cgoups 中 feature A 的。

cgroup 的默认层级

通过将 cgroup 层级系统与 systemd unit 树绑定,systemd 可以把资源管理的设置从进程级别移至应用程序级别。因此,我们可以使用 systemctl 指令,或者通过修改 systemd unit 的配置文件来管理 unit 相关的资源。

默认情况下,systemd 会自动创建 slice、scope 和 service unit 的层级(slice、scope 和 service 都是 systemd 的 unit 类型,参考《初识 systemd》),来为 cgroup 树提供统一的层级结构。

系统中运行的所有进程,都是 systemd init 进程的子进程。在资源管控方面,systemd 提供了三种 unit 类型:

  • service :一个或一组进程,由 systemd 依据 unit 配置文件启动。service 对指定进程进行封装,这样进程可以作为一个整体被启动或终止。
  • scope :一组外部创建的进程。由进程通过 fork() 函数启动和终止、之后被 systemd 在运行时注册的进程,scope 会将其封装。例如:用户会话、 容器和虚拟机被认为是 scope。
  • slice :一组按层级排列的 unit。slice 并不包含进程,但会组建一个层级,并将 scope 和 service 都放置其中。真正的进程包含在 scope 或 service 中。在这一被划分层级的树中,每一个 slice 单位的名字对应通向层级中一个位置的路径。

我们可以通过 systemd-cgls 命令来查看 cgroups 的层级结构:

1650017714089.png

service、scope 和 slice unit 被直接映射到 cgroup 树中的对象。当这些 unit 被激活时,它们会直接一一映射到由 unit 名建立的 cgroup 路径中。例如,cron.service 属于 system.slice,会直接映射到 cgroup system.slice/cron.service/ 中。
注意,所有的用户会话、虚拟机和容器进程会被自动放置在一个单独的 scope 单元中。

默认情况下,系统会创建四种 slice:

  • -.slice :根 slice
  • system.slice :所有系统 service 的默认位置
  • user.slice :所有用户会话的默认位置
  • machine.slice :所有虚拟机和 Linux 容器的默认位置

1650017745170.png

systemd(1) 系统管理器(PID=1)以 user@<em class="replaceable"><code>UID</code></em>.service 为名称启动用户管理单元实例。 每一个 systemd --user 实例都管理着一个包含该用户所有运行单元的层次结构。

每一个 user@<em class="replaceable"><code>UID</code></em>.service 单元实例都附带着一个 user-runtime-dir@<em class="replaceable"><code>UID</code></em>.service 系统单元实例, 用于创建用户运行时目录 /run/user/<em class="replaceable"><code>UID</code></em> , 并在该单元停止时自动将其删除。

用户进程可以由 user@.service 的实例启动,在这种情况下, 在系统的层次结构中,用户进程将成为该单元的一部分。 用户进程也可以在其他地方启动,例如由 sshd 或者像 gdm 这样的显示管理器启动,在这种情况下,将会形成一个 .scope 单元。 user@<em class="replaceable"><code>UID</code></em>.service 与 scope 单元都将被收集在 user-<em class="replaceable"><code>UID</code></em>.slice 单元之中。

所有 user-<em class="replaceable"><code>UID</code></em>.slice 单元都收集在 user.slice 单元之下。

针对已登录用户的资源控制可以在几个不同的层次上进行配置。 正如前文所述,因为 user.slice 包含了所有用户的进程, 所以在此 slice 上施加的资源限制将会作用于全部已登录用户的总体。 通常通过例如 /etc/systemd/system/user.slice.d/resources.conf 这样的配置片段实现。

属于单个已登录用户的全部进程都收集在 user-UID.slice 之下。 针对单个用户的资源限制可以通过此 slice 来实现(通过例如 /etc/systemd/system/user-1000.slice.d/resources.conf 这样的配置片段)。 如果想对每一个已登录用户都施加相同的资源限制,可以通过 user-.slice 单元(剪掉单元名称)的配置片段来实现。例如,配置片段 /etc/systemd/system/user-.slice.d/resources.conf 将会被包含进所有 user-UID.slice 单元中。

在一个用户登录的同时,将会自动为该用户的登录会话创建一个 .scope 单元。

通常,任何针对单元的资源控制都可以用于 user@UID.service 单元与上文提及的 slice 单元。

举例

例 1. 拥有两个已登录用户的控制组层次结构

$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ ├─user-1000.slice
│ │ ├─user@1000.service
│ │ │ ├─pulseaudio.service
│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no
│ │ │ └─gnome-terminal-server.service
│ │ │   └─init.scope
│ │ │     ├─ 4127 /usr/libexec/gnome-terminal-server
│ │ │     └─ 4198 zsh
│ │ …
│ │ └─session-4.scope
│ │   ├─ 1264 gdm-session-worker [pam/gdm-password]
│ │   ├─ 2339 /usr/bin/gnome-shell
│ │   …
│ │ ├─session-19.scope
│ │   ├─6497 sshd: zbyszek [priv]
│ │   ├─6502 sshd: zbyszek@pts/6
│ │   ├─6509 -zsh
│ │   └─6602 systemd-cgls --no-pager
│ …
│ └─user-1001.slice
│   ├─session-20.scope
│   │ ├─6675 sshd: guest [priv]
│   │ ├─6708 sshd: guest@pts/6
│   │ └─6717 -bash
│   └─user@1001.service
│     ├─init.scope
│     │ ├─6680 /usr/lib/systemd/systemd --user
│     │ └─6688 (sd-pam)
│     └─sleep.service
│       └─6706 /usr/bin/sleep 30

UID=1000 的用户通过 gdm (session-4.scope) 与 ssh (session-19.scope) 登录, 同时拥有一个用户管理单元实例(user@1000.service)。 UID=1001 的用户通过 ssh (session-20.scope) 登录, 同时拥有一个用户管理单元实例(user@1001.service)。 这些(叶子)系统单元向上构成了 user-1000.sliceuser-1001.slice 单元,进一步向上又构成了 user.slice 单元。用户单元可见于 user@.service 实例之下(pulseaudio.service, gnome-terminal-server.service, init.scope, sleep.service)。

参考文献

0

评论区