Dan Smith wrote:
DL> The CLONE_NEWNET will fail if the network namespace is not DL> compiled in. I understand this check but it looks like a little DL> random. You are not 100% sure this clone has failed because the DL> network namespace is not supported. That can be another subsystem DL> or namespace which has failed during the initialization of the DL> namespaces.
The check is performed twice, once with the basic set of flags and again with CLONE_NEWNET. If the first check fails, we assume no LXC support (as we did before). If the second fails, we assume LXC but no NETNS. Is there something else I'm missing here?
DL> Why don't you simply check the presence of the 'netns' process ?
That seems like a valid way as well, although we already do our feature checks by testing the clone. Also, by doing it this way, we have a better confirmation that an actual clone(CLONE_NEWNET) will work, IMHO.
You are not doing clone(CLONE_NEWNET) in this code. You call clone(CLONE_NEWPID|CLONE_NEWNS|CLONE_NEWUTS|CLONE_NEWUSER|CLONE_NEWIPC|SIGCHLD|CLONE_NEWNET) When this call fails, you 'assume' netns is not compiled in. I agree the clone should have returned ENOSYS in this case, but it returns EINVAL and that do not means 'netns in not active'. If you look at the processes, you have a kthread called '[netns]', which indicates the network namespaces are actives in the kernel and this is not an assumption.
DL> Concerning iproute2, I think this is the work of the installer to DL> check the dependencies, eg. the libvirt rpm depends on DL> iproute2-x.y.z version rpm.
Agreed, and I'm sure it will. Note DV's second comment here:
https://www.redhat.com/archives/libvir-list/2008-June/msg00232.html
In your code, you launch the ip command and if it fails with a particular exit code, you 'assume' netns is not supported. Another assumption ... IMHO you should rely on the package dependencies/command version. Or if you absolutely want to detect that at startup, perhaps doing "ip link help | grep netns" is more secure :)