我多年来一直致力于开发Debian stretch/4.14.75
并使用自己的自动安装程序 ( )。udev-hook + shell-script
由于它最近由于名称空间问题而中断,因此除了由automounter-script
.
虽然
# sed -i "/^MountFlags/s/=.*$/=shared/" \
/lib/systemd/system/systemd-udevd.service
让它再次变得好,我想知道是否有可能
mount(8)
或其他一些操作将命名空间一次性传播回
root
(?)命名空间。
MountFlags=slave
我认为他们违约一定有充分的理由,或者?
答案1
不,一旦在分离的挂载命名空间上运行,您就无法真正将挂载传播回根命名空间。
除了禁用挂载命名空间沙箱之外,您还可以使用systemd-mount
解决这个问题。
沙箱的基本原理
systemd 更喜欢让 udev 规则不直接挂载文件系统,而是告诉它从 udev 规则启动单元(例如挂载单元)。这就是为什么 udevd 在单独的挂载命名空间中运行(带有MountFlags=slave
),以防止规则错误或想要临时挂载文件系统以污染主机挂载的规则。
但是,当然,在您的情况下,这就是您想要通过自动安装程序脚本执行的操作。
系统挂载
您可以调整自动挂载器脚本,使其在 udevd 的单独挂载命名空间内工作,只需将调用替换mount
为systemd-mount
,这是一个与以下参数相同的工具mount
,这是一个工具,它采用与(尽可能)安装单元和自动安装单元对于它,两个单元都在瞬态/run/systemd/system
目录下创建,该目录在重新启动时不会保留。)
通过覆盖禁用挂载沙箱
如果您确实想禁用 udevd 挂载命名空间的沙箱,请使用覆盖配置文件来执行此操作,而不是修改/lib
systemd 软件包附带的配置文件(下次 apt 升级软件包时可能会破坏该配置文件)。 )
您可以使用以下命令在编辑器中打开覆盖文件:
$ sudo systemctl edit systemd-udevd
MountFlags
您可以使用以下两行重置为默认值(“共享”):
[Service]
MountFlags=
将变量设置为空字符串通常会将其重置为 systemd 中的默认值。
请注意,在最新版本的 systemd 中,现在使用它进行配置PrivateMounts=
,例如,请参阅犯罪转换 udevd 服务文件以使用它。
这凸显了覆盖的问题之一:您偏离了标准的 systemd 配置,因此您可能最终不得不不时进行调整,因为您需要额外或替代配置才能在升级到较新的 systemd 时保持其正常工作。
此外,您首先会失去将 udevd 沙箱到其自己的挂载命名空间的好处。
因此,如果使用的解决方案systemd-mount
适合您,我会推荐它而不是覆盖。
答案2
systemd 单元存储在以下位置:
/etc/systemd/system/* - local configuration
/run/systemd/system/* - runtime units
/usr/lib/systemd/system/* - units of installed packages
当你想修改某些东西时,你不应该修改/usr/lib/systemd/system/
目录中的文件,而是应该在目录中创建同名的新单元文件/etc/systemd/system/
。
从man systemd.unit
:
有两种方法可以覆盖单元文件中的供应商设置:/usr/lib/systemd/系统到/etc/systemd/系统并修改所选设置。或者,可以创建一个名为的目录单位.d/之内/etc/systemd/系统并放置一个嵌入式文件名称.conf那里只更改人们感兴趣的特定设置。请注意,如果存在多个此类插入文件,则会被读取。
第一种方法的优点是可以轻松覆盖整个单元,不再解析供应商单元。它的缺点是供应商对单元文件的改进不会自动合并到更新中。
第二种方法的优点是仅覆盖特定想要的设置,其中供应商对单元的更新会自动应用。这样做的缺点是供应商未来的某些更新可能与本地更改不兼容。
systemd
有其自己的用于安装卷的机制,如上所述这里:
systemd 负责挂载 /etc/fstab 中指定的分区和文件系统。 systemd-fstab-generator(8) 将 /etc/fstab 中的所有条目转换为 systemd 单元,这在启动时以及每当重新加载系统管理器的配置时执行。
我认为在 systemd 中使用您自己的自动安装程序会给您带来不必要的问题。