1

As far as I understand hierarchy 13 points to "name=systemd", I have been trying to run a somewhat simple lxc-execute inside of a docker dev environment with the following :

docker run -i -t --cap-add=SYS_PTRACE --cap-add=SYS_ADMIN lxc-build:phantomjs-test

lxc.conf

lxc.arch = x86_64
lxc.rootfs.path = /home/tester
lxc.uts.name = phantom_container
lxc.idmap = u 0 1000 65536
lxc.idmap = g 0 1000 65536
lxc.pty.max = 1
lxc.tty.max = 1
lxc.execute.cmd = phantomjs

lxc-execute

/home/tester # XDG_RUNTIME_DIR='' lxc-execute --name bork -f /home/tester/default.conf -l TRACE -o okay.log

trace

/home/tester # cat okay.log 
    INFO     lxc_confile - confile.c:set_config_idmaps:1575 - Read uid map: type u nsid 0 hostid 1000 range 65536
    INFO     lxc_confile - confile.c:set_config_idmaps:1575 - Read uid map: type g nsid 0 hostid 1000 range 65536
    TRACE    lxc_commands - commands.c:lxc_cmd_init:1323 - Creating abstract unix socket "/usr/local/var/lib/lxc/bork/command"
    TRACE    lxc_start - start.c:lxc_init_handler:563 - Unix domain socket 4 for command server is ready
    TRACE    lxc_start - start.c:lxc_init:578 - initialized LSM
    TRACE    lxc_start - start.c:lxc_init:584 - read seccomp policy
    TRACE    lxc_start - start.c:lxc_serve_state_clients:350 - Set container state to STARTING
    TRACE    lxc_start - start.c:lxc_serve_state_clients:353 - No state clients registered
    TRACE    lxc_start - start.c:lxc_init:591 - set container state to "STARTING"
    TRACE    lxc_start - start.c:lxc_init:619 - set environment variables
    TRACE    lxc_start - start.c:lxc_init:625 - ran pre-start hooks
    DEBUG    lxc_start - start.c:setup_signal_fd:278 - Set SIGCHLD handler with file descriptor: 5.
    TRACE    lxc_start - start.c:lxc_init:636 - set up signal fd
    DEBUG    console - console.c:lxc_console_peer_default:513 - using "/dev/tty" as peer tty device
    DEBUG    console - console.c:lxc_console_signal_init:178 - Created signal fd 9
    DEBUG    console - console.c:lxc_console_winsz:86 - Set window size to 204 columns and 59 rows
    TRACE    lxc_start - start.c:lxc_init:643 - created console
    TRACE    lxc_conf - conf.c:lxc_ttys_shift_ids:2870 - chowned console "/dev/pts/1"
    TRACE    lxc_start - start.c:lxc_init:649 - shifted tty ids
    INFO     lxc_start - start.c:lxc_init:651 - container "bork" is initialized
    DEBUG    storage - storage/storage.c:storage_query:252 - Detected rootfs type "dir"
    INFO     lxc_cgroup - cgroups/cgroup.c:cgroup_init:67 - cgroup driver cgroupfs initing for bork

    # I've been really focused on this error
    ERROR    lxc_cgfs - cgroups/cgfs.c:lxc_cgroupfs_create:901 - Could not find writable mount point for cgroup hierarchy 13 while trying to create cgroup.


    ERROR    lxc_start - start.c:lxc_spawn:1245 - Failed creating cgroups.
    DEBUG    lxc_network - network.c:lxc_delete_network:3123 - Deleted network devices
    TRACE    lxc_start - start.c:lxc_serve_state_clients:350 - Set container state to ABORTING
    TRACE    lxc_start - start.c:lxc_serve_state_clients:353 - No state clients registered
    ERROR    lxc_start - start.c:__lxc_start:1503 - Failed to spawn container "bork".
    TRACE    lxc_start - start.c:lxc_serve_state_clients:350 - Set container state to STOPPING
    TRACE    lxc_start - start.c:lxc_serve_state_clients:353 - No state clients registered
    TRACE    lxc_start - start.c:lxc_serve_state_clients:350 - Set container state to STOPPED
    TRACE    lxc_start - start.c:lxc_serve_state_clients:353 - No state clients registered

I have been attempting to containerize one executable, and I am beginning to wonder if maybe i should just be using only cgroups, as this whole containers in containers stuff seems a bit confusing.

tester@04de411cd0fe:~$ cat /proc/1/cgroup

13:name=systemd:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
12:pids:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
11:hugetlb:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
10:net_prio:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
9:perf_event:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
8:net_cls:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
7:freezer:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
6:devices:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
5:memory:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
4:blkio:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
3:cpuacct:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
2:cpu:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f
1:cpuset:/docker-ce/docker/04de411cd0fe22b59d5508bbfc137631d1867b9a56104d9db80ca66b061f4b1f

In what cases would systemd need to be mounted as writable? Why would lxc/systemd be looking for me to mount systemd?

tester@04de411cd0fe:~$ mount | grep cgroup

tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,relatime,mode=755)
cpuset on /sys/fs/cgroup/cpuset type cgroup (ro,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (ro,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpuacct)
blkio on /sys/fs/cgroup/blkio type cgroup (ro,nosuid,nodev,noexec,relatime,blkio)
memory on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory)
devices on /sys/fs/cgroup/devices type cgroup (ro,nosuid,nodev,noexec,relatime,devices)
freezer on /sys/fs/cgroup/freezer type cgroup (ro,nosuid,nodev,noexec,relatime,freezer)
net_cls on /sys/fs/cgroup/net_cls type cgroup (ro,nosuid,nodev,noexec,relatime,net_cls)
perf_event on /sys/fs/cgroup/perf_event type cgroup (ro,nosuid,nodev,noexec,relatime,perf_event)
net_prio on /sys/fs/cgroup/net_prio type cgroup (ro,nosuid,nodev,noexec,relatime,net_prio)
hugetlb on /sys/fs/cgroup/hugetlb type cgroup (ro,nosuid,nodev,noexec,relatime,hugetlb)
pids on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,mode=755)


/home/tester # cat /proc/cgroups

#subsys_name    hierarchy   num_cgroups enabled
cpuset  1   22  1
cpu 2   22  1
cpuacct 3   22  1
blkio   4   22  1
memory  5   23  1
devices 6   22  1
freezer 7   22  1
net_cls 8   22  1
perf_event  9   22  1
net_prio    10  22  1
hugetlb 11  22  1
pids    12  22  1

I have tried using docker images for ubuntu 17.04, 16.04, and alpine:latest, all with the same results. I have tried using lxc 2.07, 2.08, and 2.1.1, mostly with the same results.

During my learning process I was able to resolve similar errors:

  • Could not find writable mount point for cgroup hierarchy 4 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 5 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 6 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 7 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 8 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 9 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 10 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 11 while trying to create cgroup
  • Could not find writable mount point for cgroup hierarchy 12 while trying to create cgroup

Using 2 different methods I think I resolved the standard cgroup hierarchy mounting stuff for the first 12, but 13 for some reason isn't working:

  1. mount -t cgroup cpuset -o cpuset /sys/fs/cgroup/cpuset/
  2. cd project && mkdir -p sys/fs/cgroup/{net_prio,pids,hugetlb,freezer,cpuset,cpu,devices,perf_event,memory,cpuacct,net_cls,blkio} # and then using rootfs, or a mount.entry type config

Some more related info:

cat /etc/*-release

3.6.2
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.6.2
PRETTY_NAME="Alpine Linux v3.6"
HOME_URL="http://alpinelinux.org"
BUG_REPORT_URL="http://bugs.alpinelinux.org"

uname -a

Linux 8fd6247b5665 4.9.60-linuxkit-aufs #1 SMP Mon Nov 6 16:00:12 UTC 2017 x86_64 Linux

lxc-execute --version

2.1.0-devel

docker version

Version 17.11.0-ce-mac40 (20561)
Channel: edge
d8fd0f1f4a

How closely related are these pull requests:

Some related thoughts/questions have been that I shouldn't use containers in containers, and should just use a full VM ( doesn't solve the problem of usability ).

  • I could try to recompile? systemd?
  • maybe there's something to do with the kernel boot params?
  • maybe i'm using the wrong versions of cgroupv1 and cgroupv2?
  • Is it possible to disable trying to mount cgroup hierarchies?
  • Is this related to how docker does /sbin/init and starts the initial cgroup namespacing?

Any help would be greatly appreciated.

Also possibly related:

So some more research and i've found this information as well, which shows some more information on initial cgroup cgfs stuff, possibly related to name=systemd:

/home/tester # cat /usr/share/doc/lxcfs/README.Debian
...
/home/tester # cat /usr/share/pam-configs/cgfs

Name: Create cgroups for user login sessions
Default: yes
Priority: 0
Session-Type: Additional
Session:
    optional    pam_cgfs.so -c freezer,memory,name=systemd


/home/tester # cat /etc/pam.d/common-session

session [default=1]         pam_permit.so
session requisite           pam_deny.so
session required            pam_permit.so
session optional            pam_umask.so
session required    pam_unix.so 
session optional    pam_systemd.so 
session optional    pam_cgfs.so -c freezer,memory,name=systemd

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.