nsgroup autoremoving

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 ?

Quoted 12 lines · Daniel Lezcano

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.

Quoted 4 lines

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

Quoted 24 lines · Serge E. Hallyn

Quoted 13 lines · Daniel Lezcano

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.

Quoted 5 lines

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:

Quoted 17 lines

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 ?

Quoted 42 lines · Daniel Lezcano

Quoted 24 lines · Serge E. Hallyn

Quoted 13 lines · Daniel Lezcano

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.

Quoted 5 lines

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:

Quoted 17 lines

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

Quoted 3 lines

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 ?

I assume notify_on_release is per-hierarchy. So you're just asking about manually created cgroups in a hierarchy which has ns mounted, right?

I suppose you could use a naming convention and do some name checking in the release_agent to not delete manually created ones.

Would that be too much of a hassle?

Maybe you're right. Maybe we should tag auto-created cgroups, and auto-remove them.

It's more convenient for me that way...
Paul, would you have any objections? Daniel do you have a patch written?