systemd-chroot 部分
先声明一下, 是没有 systemd-chroot 这个命令, 只是仿照 systemd-nspawn 而已.
systemd 的 chroot 存在于 .service 文件里, 有两个参数
RootDirectory=
RootImage=
(man systemd.exec)
可供使用 chroot.
直接选了最经典的 direcotory, 根本没有试 image.
这里先说一个遇到的不影响使用, 但影响收尾的问题. 因为后面说的有些地方, 因为这个
问题进行了一些调整.
这个文件简单来说, 就是在 image mount 到一个目录后, 然后用 chroot 方式是运行了
软件 8, 9 个小时是后关闭软件, 最后 umount. 但就是这个 unmount 不能成功结束, 从
lsblk 可以看到, 虽然其挂载点, 没有了, 但是代表映像文件的 loopN 依然在.
在我用两个系统上(都是 18.04, 不过内核不同, 一个是默认的 4.15, 一个是 hwe 5.3),
一个用的是 xfs, xfs 遇到这个问题, 是没法 systemd-nspawn --image=, 另一个是 ext4
, 这个倒是可以 systemd-nspawn --image=, 更新也是可以. 但问题在于, 即便重新
mount 后, 软件的版本还是老版本, 除非确实 unmount, 在 mount 后才可以看到改变.
这时只能重启解决. 但每次重启都很麻烦. 想要解决这个方法, 所以想要解决这个问题.
最先想到的是, 有进程没结束. 但不应该, 因为用的 KillMode 是 control-group(man
systemd.kill), 就是防止有进程没结束, 一直挂在那. 也分析还在运行的进程, 没有还在
运行的. 用 lsof 找也是一样的.
然后想到, 会不会是结束时, 没有处理好? 由于我运行了 N 个不同的由 chroot 驱动的软
件, 在全部停止时, 会不会产生了某种竞争冲突? 于是在每个进程结束运行后, 加了一个
sleep 3 延时, 但实际结果看, 也不是这个原因.
接着将注意力转移到 umount 命令上. 添加了针对 loopdevice 文件的 --detach-loop 参
数, 同样也没有效果. 又添加 man 里面提到的环境变量 LIBMOUNT_DEBUG=all, 跟踪关闭
过程. 但是从输出的信息看, 没有发现什么特别的. 用 strace 去跟踪也是同样的.
现在又想到, 会不会是一开始就出问题了. 因为我把启动 chroot 的过程, 分为几个服务
进行. 因为担心存在竞争冲突, 甚至把 mount image 加了一个互斥判断. 当然也包括启动
软件前的 sleep 延时. 但依然没有解决这个问题.
目前唯一知道的是, 只要一个软件运行的时间, 有 8, 9 个小时, 那么在结束运行后,
umount 不能完成的可能性就非常高. 现在只是解决了因为这个问题导致不能更新软件的问
题.
先声明一下, 是没有 systemd-chroot 这个命令, 只是仿照 systemd-nspawn 而已.
systemd 的 chroot 存在于 .service 文件里, 有两个参数
RootDirectory=
RootImage=
(man systemd.exec)
可供使用 chroot.
直接选了最经典的 direcotory, 根本没有试 image.
这里先说一个遇到的不影响使用, 但影响收尾的问题. 因为后面说的有些地方, 因为这个
问题进行了一些调整.
这个文件简单来说, 就是在 image mount 到一个目录后, 然后用 chroot 方式是运行了
软件 8, 9 个小时是后关闭软件, 最后 umount. 但就是这个 unmount 不能成功结束, 从
lsblk 可以看到, 虽然其挂载点, 没有了, 但是代表映像文件的 loopN 依然在.
在我用两个系统上(都是 18.04, 不过内核不同, 一个是默认的 4.15, 一个是 hwe 5.3),
一个用的是 xfs, xfs 遇到这个问题, 是没法 systemd-nspawn --image=, 另一个是 ext4
, 这个倒是可以 systemd-nspawn --image=, 更新也是可以. 但问题在于, 即便重新
mount 后, 软件的版本还是老版本, 除非确实 unmount, 在 mount 后才可以看到改变.
这时只能重启解决. 但每次重启都很麻烦. 想要解决这个方法, 所以想要解决这个问题.
最先想到的是, 有进程没结束. 但不应该, 因为用的 KillMode 是 control-group(man
systemd.kill), 就是防止有进程没结束, 一直挂在那. 也分析还在运行的进程, 没有还在
运行的. 用 lsof 找也是一样的.
然后想到, 会不会是结束时, 没有处理好? 由于我运行了 N 个不同的由 chroot 驱动的软
件, 在全部停止时, 会不会产生了某种竞争冲突? 于是在每个进程结束运行后, 加了一个
sleep 3 延时, 但实际结果看, 也不是这个原因.
接着将注意力转移到 umount 命令上. 添加了针对 loopdevice 文件的 --detach-loop 参
数, 同样也没有效果. 又添加 man 里面提到的环境变量 LIBMOUNT_DEBUG=all, 跟踪关闭
过程. 但是从输出的信息看, 没有发现什么特别的. 用 strace 去跟踪也是同样的.
现在又想到, 会不会是一开始就出问题了. 因为我把启动 chroot 的过程, 分为几个服务
进行. 因为担心存在竞争冲突, 甚至把 mount image 加了一个互斥判断. 当然也包括启动
软件前的 sleep 延时. 但依然没有解决这个问题.
目前唯一知道的是, 只要一个软件运行的时间, 有 8, 9 个小时, 那么在结束运行后,
umount 不能完成的可能性就非常高. 现在只是解决了因为这个问题导致不能更新软件的问
题.