Serge E. Hallyn wrote: > Quoting Daniel Lezcano (daniel.lezcano@xxxxxxx): > >> Hi, >> >> While trying to unshare a namespace with the clone syscall with an >> inifinite loop, I got an EEXIST. >> That looks weird to have such syscall returning EEXIST ... :) >> >> After investigating, it appears the ns_cgroup creates automatically a >> control group named with the pid number when we call the clone syscall >> with a namespace parameter and when the namespace exits, the control >> group is not automatically removed. So when the pid numbers are recycled >> we conflict with a previous ns_cgroup name and the clone fails. >> >> IMHO, if the nsgroup is automatically created, it should automatically >> destroyed, otherwise what will happen to application using the >> namespaces (eg. mount namespace) wrote before nsgroup appeared ? >> > > but you can have it automatically destroyed. I.e. I did the > following: > > mount -t cgroup -o freezer,ns freezer /cgroup > cat > /bin/release_cgroup.sh << EOF > #!/bin/sh > echo "Removing dead cgroup .$*." >> /var/log/cgroup > rmdir /cgroup/$* >> /var/log/cgroup 2>&1 > echo "return value was $?" >> /var/log/cgroup > EOF > echo /bin/release_cgroup.sh > /cgroup/release_agent > echo 1 > /cgroup/notify_on_release > chmod ugo+x /bin/release_cgroup.sh > ns_exec -m /bin/sh > ls /cgroup` > 3581 notify_on_release release_agent tasks > exit > ls /cgroup > notify_on_release release_agent tasks > Assuming you mount with all the subsystems, this script will destroy the non-nsgroup too. Each time I create a control group manually, I have to unset the notify_on_release, right ? _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers