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

[Karel Zak]

On Mon, Nov 02, 2015 at 03:36:49PM +, Richard Maw wrote:
> > for that? If not is there a kernel interface to create one?
> 
> I don't know of any utilities, but /proc/$pid/ns/net is a symlink pointing
> to a magic file that refers to the network namespace.

I think about "lsns" command to list namespaces where /proc/$pid/ns/*
is different to /proc/$ppid/ns/*, but not sure how usable it will be
and what information list. Suggestions & comments?

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mon, 02.11.15 20:35, Aliaksei Sheshka (sheshka...@gmail.com) wrote:

> >
> > Note that all units you join need to have PrivateNetwork=yes set if
> > they shall live in the same namespace. Did both your units have this set?
> 
> I have my unit c7-test like that:
> 
> ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot
> --link-journal=try-guest --network-macvlan=eth0 --settings=override
> --machine=c7-test
> 
> --networ-macvlan assumes  PrivateNetwork as I understand.
> If I add additional  "PrivateNetwork=yes" to that nspawn unit, it
> won't work, since, obviously, eth0 is no longer available.

Well, not only that, but nspawn opens a new network namespace for the
container as soon as you use any of the --network-xyz or
--private-network switches, but nspawn itself will stay outside...

> In short my goal to have macvlan enabled systemd-nspawn container
> running. Once it's up, I would like to run a daemon withing that
> container ip namespace using binary located on the host system.
> Current 'nsenter' solution looks not that elegant.  Perhaps there is a
> better way to achieve that.

I don't see how, sorry...

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Aliaksei Sheshka]

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?
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?

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?

Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Richard Maw]

On Mon, Nov 02, 2015 at 09:27:42AM -0500, Aliaksei Sheshka 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?
> 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,

This is because `ip netns add` and the rest
work by bind-mounting the network namespace to a file.

Systemd does not do this when creating network namespaces,
since then the namespaces can be bound to the lifetime of the processes,
and you don't need an explicit namespace cleanup step.

However since you entered the namespace manually,
and your process is not in the cgroup of the container,
your network daemon process is neither managed by the nspawn cgroup,
nor any systemd running in the container,
so as far as systemd is concerned, it successfully shut it down.

> is there any other utility
> for that? If not is there a kernel interface to create one?

I don't know of any utilities, but /proc/$pid/ns/net is a symlink pointing
to a magic file that refers to the network namespace.

You could have a tool enumerate all your processes and stat the symlinks,
though it's a privileged operation to view someone else's namespaces
so you'd have to run the following with sudo:

#!/usr/bin/python

from collections import defaultdict
from os import listdir, stat
from os.path import join

namespaces = defaultdict(set)

for fn in listdir('/proc'):
if all(c.isdigit() for c in fn):
pid = int(fn)
ino = stat(join('/proc', fn, 'ns', 'net')).st_ino
namespaces[ino].add(pid)

print("You have processes in %d namespaces" % len(namespaces))
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mon, 02.11.15 09:27, Aliaksei Sheshka (sheshka...@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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Aliaksei Sheshka]

On Mon, Nov 2, 2015 at 1:05 PM, Lennart Poettering
 wrote:


>
> 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...

Perhaps, I've tried

[Unit]
Description=mydaemon withing c7-test network context
After=network.target

[Service]
TimeoutStartSec=10
ExecStart=/usr/sbin/mydaemon
JoinsNamespaceOf=c7-test.service
PrivateTmp=yes
PrivateNetwork=yes

[Install]
WantedBy=multi-user.target


but looks likes it creates new namespace, because 'mydaemon' sees only
127.0.0.1 with such unit.
c7-test unit is 100% running.
Another question, would 'machinectl poweroff c7-test' terminate
[properly configured] 'mydaemon' unit as well ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Mon, 02.11.15 14:52, Aliaksei Sheshka (sheshka...@gmail.com) wrote:

> On Mon, Nov 2, 2015 at 1:05 PM, Lennart Poettering
>  wrote:
> 
> 
> >
> > 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...
> 
> Perhaps, I've tried
> 
> [Unit]
> Description=mydaemon withing c7-test network context
> After=network.target
> 
> [Service]
> TimeoutStartSec=10
> ExecStart=/usr/sbin/mydaemon
> JoinsNamespaceOf=c7-test.service
> PrivateTmp=yes
> PrivateNetwork=yes
> 
> [Install]
> WantedBy=multi-user.target
> 
> 
> but looks likes it creates new namespace, because 'mydaemon' sees only
> 127.0.0.1 with such unit.
> c7-test unit is 100% running.
> Another question, would 'machinectl poweroff c7-test' terminate
> [properly configured] 'mydaemon' unit as well ?

Note that all units you join need to have PrivateNetwork=yes set if
they shall live in the same namespace. Did both your units have this set?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Aliaksei Sheshka]

>
> Note that all units you join need to have PrivateNetwork=yes set if
> they shall live in the same namespace. Did both your units have this set?

I have my unit c7-test like that:

ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot
--link-journal=try-guest --network-macvlan=eth0 --settings=override
--machine=c7-test

--networ-macvlan assumes  PrivateNetwork as I understand.
If I add additional  "PrivateNetwork=yes" to that nspawn unit, it
won't work, since, obviously, eth0 is no longer available.

In short my goal to have macvlan enabled systemd-nspawn container
running. Once it's up, I would like to run a daemon withing that
container ip namespace using binary located on the host system.
Current 'nsenter' solution looks not that elegant.  Perhaps there is a
better way to achieve that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel