Hacker News new | ask | show | jobs
by vishvananda 3310 days ago
Author of the go netlink library here. I've run into this issue a number of times. There has been conversation in the past about adding some kind of new runtime command like LockOSThread to prevent new threads from being spawned, but it didn't gain any momentum.

Even though I am a big fan of go, I've personally built two container runtimes in other languages do to the namespace clumsiness.

Personally, I think rust is an excellent alternative for namespace utilities.

EDIT: there is more information and links in the issue in the netns library: https://github.com/vishvananda/netns/issues/17
3 comments
mrjana 3310 days ago
One way to alleviate the problem at least for netlink library is to create a function which calls runtimeLockOSThread, sets into the required namespace and then opens a netlink socket using only raw syscall apis. One has to be careful in this code path to not invoke go runtime (i.e both socket and setns should be raw syscall apis) and not even trigger any allocations so that go runtime doesn't get a chance a spin a new OS thread. Once a socket is created in the required namespace you can get back to the caller namespace and return the socket fd. Now this socket fd is bound to that namespace and all netlink operations on that socket will happen in the target namespace.

Disclaimer: I am one of the original libnetwork authors and we have been aware of this issue with go for some time now.

link
bogomipz 3310 days ago
>" I've personally built two container runtimes in other languages do to the namespace clumsiness."

Can you share any details on those other container runtimes?

link
vishvananda 3310 days ago
One was a simplified runtime in c, similar to a stripped down version of systemd-nspawn. I can hopefully share the other one in a few weeks. I'm going through an open source approval process for it.
link
bogomipz 3310 days ago
Thanks. It's an interesting topic. I hope you post it on HN then.
link
cyphar 3310 days ago
I completely agree, and I've been coming up with some ideas (based on runc) to see what sort of improvements can you have if you do a full redesign in a language that isn't as painful as Go to use.

At the moment I'm incredibly busy, but later this year I might be able to start working on that too.

link