Go and Linux network namespaces

[Milos Gajdos]

I've been playing around with Network namespaces recently. I put together a simple code, built it and noticed something very weird happening.

The code is as follows:

http://play.golang.org/p/PYI2E05LnF

Now, when you run this code on Ubuntu Trusty 14.04, I'm seeing something weird happening. This happens when you run the binary several times in a row.

Sometimes it prints out all Host's interfaces, sometimes it simply prints out just a loopback interface which means that the range loop at the end of the program seems to be executing once when the namespace is still attached and sometimes when it's already been detached.

I'm totally confused why this is happening but I'm thinking it's either my code or maybe I'm just missing out something in terms of the Go program execution or some kernel stuff.

Anyone ideas ?

Thanks!

[Jan Mercl]

On Sat, Jun 14, 2014 at 8:39 PM, Milos Gajdos <milosg...@gmail.com> wrote:
> Anyone ideas ?

Do not ignore the error returned at line 47.

-j

[S.Çağlar Onur]

Hi,

I agree that error shouldn't be ignored but I'm not sure whether that is OP's problem as it looks like he either gets the loopback interface (as expected) or the full list of interfaces from the host which shows that the process is not in the newly created network namespace. 

If I'm not wrong, net.Interfaces calls http://golang.org/src/pkg/net/interface_linux.go#L16 and that function either returns nil and error or result and nil but not partial results and error. Milos, I suggest writing the same code in C to rule out kernel (or try using unshare [from util-linux-ng] or lxc-unshare [from lxc] binaries to do the the same) from the picture. In theory unshare should be moving the calling process into the new network namespace but maybe it only moves the calling thread and this causes some problems with the go runtime?

 

-j

Best, 

[Julian Phillips]

On 14/06/2014 19:39, Milos Gajdos wrote:
> I've been playing around with Network namespaces recently. I put
> together a
> simple code, built it and noticed something very weird happening.
>
> The code is as follows:
>
> http://play.golang.org/p/PYI2E05LnF
>
> Now, when you run this code on Ubuntu Trusty 14.04, I'm seeing
> something

> weird happening. This happens when you run the binary *several times in
> a
> row*.

>
> Sometimes it prints out all Host's interfaces, sometimes it simply
> prints
> out just a loopback interface which means that the range loop at the
> end of
> the program seems to be executing once when the namespace is still
> attached
> and sometimes when it's already been detached.
>
> I'm totally confused why this is happening but I'm thinking it's either
> my
> code or maybe I'm just missing out something in terms of the Go program
> execution or some kernel stuff.
>
> Anyone ideas ?

1) unshare affects the current thread
2) Go doesn't guarantee to keep the code running on one thread.

http://play.golang.org/p/DY65qnWsAD

Playing with this sort of syscall without co-operation from the Go
runtime can be quite tricky to manager.

--
Julian

[Milos Gajdos]

Thanks everyone,

this is superuseful to know about.

I will try to dig in more into this as it interests me a lot

M.

[Milos Gajdos]

After locking the main goroutine to one OS thread, the behaviour got indeed stable - I no longer notice any "craziness" ( seeming craziness as what I was seeing and thought was crazy was actually correct behavior) .

However, what I still don't get is the results returned. I'd expect after unmounting and unlinking the namespace interface the net.Intefaces() to return all of Host's interfaces, yet it still does return the new net namespace interfaces.

I'm guessing like Julian suggested there needs to be more runtime coordination to achieve what I'm after.

M.

[Julian Phillips]

On 16/06/2014 02:42, Milos Gajdos wrote:
> After locking the main goroutine to one OS thread, the behaviour got
> indeed
> stable - I no longer notice any "craziness" ( seeming craziness as what
> I
> was seeing and thought was crazy was actually correct behavior) .
>
> However, what I still don't get is the results returned. I'd expect
> after
> unmounting and unlinking the namespace interface the net.Intefaces() to
> return all of Host's interfaces, yet it still does return the new net
> namespace interfaces.
>
> I'm guessing like Julian suggested there needs to be more runtime
> coordination to achieve what I'm after.

I think this is more to do with a misunderstanding of how the namespaces
work. /var/run/netns is how you create a persistent name for a
namespace - but you don't have to use it. The unshare call will create
a new namespace, and it will exist as long as it is referenced (which
includes the persistent name and any processes in the namespace - i.e.
yours). Unmounting & deleting the entry in /var/run/netns removes the
persistent name (so you can't then access the namespace with "ip netns
..." etc), but it doesn't destroy the namespace or take your process out
of it.

Also, /var/run/netns is just a directory, you shouldn't be doing any
mounts with that (you will just break access to any existing
namespaces).

--
Julian

[Milos Gajdos]

I have come across an interesting insight into Golang runtime and how golang schedules goroutines to OS threads which makes all the hints from Florian, Julian etc more clear to me.

In case anyone's interested here's the blogpost:

http://morsmachine.dk/go-scheduler

M.