Re: [systemd-devel] systemd-nspawn and process spawning using nsenter issue
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 Zakhttp://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
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
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
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
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
On Mon, Nov 2, 2015 at 1:05 PM, Lennart Poetteringwrote: > > 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
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
> > 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