[systemd-devel] systemd-nspawn and process spawning using nsenter issue

[Lennart Poettering]

On Mon, 02.11.15 09:27, Aliaksei Sheshka (sheshkaoss at gmail.com) wrote:

> Hello!
> 
> I have some systemd-nspawn and namespace related question.
> Assume following commands,
> 
> $ systemctl start c7-test #starring our container
> $ systemctl status c7-test #checking if it is running and looking for
> inside /usr/lib/systemd/systemd process
> $ nsenter -t 22333 -n /usr/local/sbin/custom-network-daemon  #starting
> our network daemon located on the host filesystem but withing
> container network namespace
> 
> I have a strong reason doing so, let say one need to modify clock on
> the host machine, while container provides very special routing table
> - it is oversimplification, but somewhat my use case.
> 
> My questions are
> a) Once container c7-test shut down using 'machinectl poweroff
> c7-test' how one can know what some processes are still running
> withing that network context?

I am not aware of any way how you can enumerate namespaces on Linux,
or their members. Usually you combine them with cgroups or suchlike,
and you can enumerate those, but if you make them go away you have no
handle anymore.

As suggested by Richard, you can pin the namespace if you like via
bind mounts, but systemd won't do that for you, and enumeration still
isn't nice if you (you'd have to compare the ns files in /proc to
match up processes)

> My  /usr/local/sbin/custom-network-daemon is perfectly running after
> c7-tets was shut down, which it obviously expected behavior.
> 
> b) Is there a generic method to list currently active namespaces?
> machinectl does not show as expected, since it's a machine lister and
> machine is not running.
> 'ip netns list' is not listing them either, if there any other utility
> for that? If not is there a kernel interface to create one?

I am not aware of any. machined keeps tracks of machines, that's
really what it is about, but if you shut down the machine and just
keep the net namespace part of it alive, then of course, machined
won't know it. ip netns is based on pinning net namespaces via bind
mounts, but we don't do that with nspawn.

> c) Since /usr/local/sbin/custom-network-daemon is still running
> withing previously created by 'systemctl start c7-test' network
> namespace, one can't start same container again properly -
> while container starts, networking fails silently in case of
> --network-macvlan=eth0, one just can't bring inside interface UP.
> Should systemd-nspawn fail with error in such cases?

Hmm, of course, this should really generate an error and fail... 

BTW: another way to deal with network namespaces in systemd is via
PrivateNetwork=yes and JoinsNamespaceOf=, but I am not whether that
matches what you want to do...

Lennart

-- 
Lennart Poettering, Red Hat