☰

为什么这个脚本如果以用户身份运行则工作正常，但如果从 rc.local 运行则失败？

tag-icon • tag-icon lxc
为什么这个脚本如果以用户身份运行则工作正常，但如果从 rc.local 运行则失败？

我在 Debian 上使用 lxc 非特权容器时遇到了一些麻烦。我遵循这个方法：

a)我在 /var/lxcunpriv 中创建无权限的用户 home

useradd -m -d /var/lxcunpriv lxcunpriv

b)我安装所需的包

apt -y install lxc libvirt0 libpam-cgroup libpam-cgfs bridge-utils cgroupfs-mount

c)我更改文件 lxc-net vim /etc/default/lxc-net

USE_LXC_BRIDGE="true"

d)我重新启动lxc-net

systemctl restart lxc-net

e）检查，全绿色（工作正常）

lxc-checkconfig

f)我应用这个

sh -c 'echo "kernel.unprivileged_userns_clone=1" > /etc/sysctl.d/80-lxc-userns.conf'
sysctl -w -p --system

g）作为非 root 用户，我这样做了

cat /etc/s*id|grep $USER

h)它返回100000-165536，所以......

usermod --add-subuids 100000-165536 lxcunpriv
usermod --add-subgids 100000-165536 lxcunpriv

i）我在 /var/lxcunpriv 上授予了一些权限

cd /var/lxcunpriv
setfacl -m u:100000:x . .local .local/share

l)我配置用户网，bridge1是我的网桥名称

echo "lxcunpriv veth bridge1 10"| tee -i /etc/lxc/lxc-usernet

m）我创建目录

su - lxcunpriv
mkdir -p .config/lxc

n) 然后..

echo \
'lxc.include = /etc/lxc/default.conf
# Subuids and subgids mapping
lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536
# "Secure" mounting
lxc.mount.auto = proc:mixed sys:ro cgroup:mixed
lxc.apparmor.profile = unconfined
 
# Network configuration
lxc.network.type = veth
lxc.network.link = bridge1
lxc.network.flags = up
lxc.network.hwaddr = 00:FF:xx:xx:xx:xx'>.config/lxc/default.conf

o）我编辑/etc/lxc/default.conf

lxc.network.type = veth
lxc.network.link = bridge1

p)更新.config/lxc/default.conf

lxc-update-config -c .config/lxc/default.conf

q)我创建第一个容器

lxc-create --name mylinux -t download
lxc-start --name mylinux
lxc-attach --name mylinux

现在的问题是，当我启动容器时......

lxc-start --name mylinux
lxc-start: mylinux: lxccontainer.c: wait_on_daemonized_start: 833 No such file or directory - Failed to receive the container state
lxc-start: mylinux: tools/lxc_start.c: main: 330 The container failed to start
lxc-start: mylinux: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode
lxc-start: mylinux: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options

在论坛上搜索我发现了这个解决方法

#!/bin/sh
printf '\n\033[42mCreating cgroup hierarchy\033[m\n\n' &&
for d in /sys/fs/cgroup/*; do
        f=$(basename $d)
        echo "looking at $f"
        if [ "$f" = "cpuset" ]; then
                echo 1 | sudo tee -a $d/cgroup.clone_children;
        elif [ "$f" = "memory" ]; then
                echo 1 | sudo tee -a $d/memory.use_hierarchy;
        fi
        sudo mkdir -p $d/$USER
        sudo chown -R $USER $d/$USER
        # add current process to cgroup
       echo $PPID > $d/$USER/tasks
done

sh workaround.sh

在线给我一个“权限被拒绝” echo $PPID > $d/$USER/tasks 但有效。

lxc-start -n mylinux
echo $?
0

现在问题来了。我希望容器在启动时启动（它们没有特权），所以 lxc-autostart 不起作用我已经创建了文件 /etc/rc.local，但失败了我尝试过这种方式

#!/bin/bash
# Action at boot

start() {
su - lxcunpriv -c "lxc-start -n mylinux"
su - lxcunpriv -c "lxc-start -n myothercontainer"
....
}

在这种情况下失败并出现错误

  lxc-start: mylinux: lxccontainer.c: wait_on_daemonized_start: 833 No such file or directory - Failed to receive the container state
    lxc-start: mylinux: tools/lxc_start.c: main: 330 The container failed to start
    lxc-start: mylinux: tools/lxc_start.c: main: 333 To get more details, run the container in foreground mode
    lxc-start: mylinux: tools/lxc_start.c: main: 336 Additional information can be obtained by setting the --logfile and --logpriority options

这也是从 rc.local 执行“解决方法”脚本

su - lxcunpriv <<EOF
sh workaround.sh
lxc-start -n myothercontainer
EOF

在这种情况下，解决方法可以运行，但 lxc-start 命令失败并出现相同的错误

 lxc-start --name mylinux
    lxc-start: mylinux: lxccontainer.c: wait_on_daemonized_start: 833 No such file or directory - Failed to receive the container state...

当然如果我这样做

su - lxcunpriv
sh workaround.sh
lxc-start -n mylinux

它可以工作，为什么不能在 rc-local 上工作？

答案1

找到解决方案我编辑 rc.local

而不是那些线

su - lxcunpriv <<EOF
sh workaround.sh
lxc-start -n myothercontainer
EOF

正确的线路是那些

start() {
su - lxcunpriv <<EOF
/var/lxcunpriv/workaround.sh
lxc-start --name mycontainer
lxc-start --name myothercontainer
...
EOF    
}

容器启动。问题出在脚本之前的“sh”一词，它启动另一个子 shell 并消除解决方法脚本的效果。

相关内容