Re: [systemd-devel] SHM parameters on nspawn containers
Hi, Ohne way is to use an More recent Kernel, with 3.16+ the Kernel defaults for These values where changed to unlimeted Regards Florian Von meinem iPhone gesendet Am 26.08.2015 um 17:34 schrieb Chris Bell cwb...@narmos.org: Hello all, I'm attempting to run GitLab (with postgresql) on a CentOS 7 container with systemd-nspawn. Postgre keeps failing, because it tries to allocate more shared memory than the container seems to allow. I cannot use sysctl to write the kernel.shmmax and kernel.shmall properties, since /sys isn't *real* (sysctl -w fails with 'read-only file system'). I have the values set correctly in the host machine, but they do not seem to propagate/be available to the container. Is there any way I can set (increase) the kernel.shmmax and kernel.shmall values in the container? Host: systemd 224 on Arch LTS Kernel (3.14.51) Guest: systemd 208 on CentOS 7 container Thanks, Chris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn network interface name collisions
Hi, if i understnd this correct, the network interface names (veth and macvlan) are created with the frist 11 Caracters from the Containername (Machinename). Now if you use similar names for conatiners, like com.$company.$devision.$name1 com.$company.$devision.$name2 com.$company.$devision.$name3 the network device name handling is broken. I tryed to prefix the machinename with a uuid (uuidgen) but the the names are to long. Why not using a 11 Caracter uuid / random for network interface names, and avoid all the naming trouble? regards Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: systemd-nspawn network interface name collisions
forgot the list -- Forwarded message -- From: Florian Koch florian.koch1...@gmail.com Date: 2015-06-18 22:03 GMT+02:00 Subject: Re: [systemd-devel] systemd-nspawn network interface name collisions To: Lennart Poettering lenn...@poettering.net 2015-06-18 18:42 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Thu, 18.06.15 18:27, Florian Koch (florian.koch1...@gmail.com) wrote: Hi, if i understnd this correct, the network interface names (veth and macvlan) are created with the frist 11 Caracters from the Containername (Machinename). IFNAMSIZ emposed by the Linux kernel is 16, and we need three chars for the prefix ve- and one for the trailing NUL byte. makes 12 chars. Thank you for the clarification Now if you use similar names for conatiners, like com.$company.$devision.$name1 com.$company.$devision.$name2 com.$company.$devision.$name3 the network device name handling is broken. I tryed to prefix the machinename with a uuid (uuidgen) but the the names are to long. Why not using a 11 Caracter uuid / random for network interface names, and avoid all the naming trouble? Well, because we want to keep things easy to grok for users. If you type ip link and see the container names for the veth links, then that's certainly a lot more useful than seeing some random gibberish that is totally understandable, but what is with macvlan interfaces? these are not shown in ip link (they are moved to the container namespace) The macvlan are my main Problem , we do not use veth interfaces. But i think there is another Thread about this Problem too, with a proposed fix http://lists.freedesktop.org/archives/systemd-devel/2015-June/033142.html I'd be willing to make this configurable: --network-veth→ as it is now, host is called ve-container-name and container side is called host0 --network-veth=foo→ creates a veth link with both sides named foo --network-veth=foo:bar→ host side called foo, container side called bar. At the same time we should open this up so that multiple links can be created, not just one. sounds good. Happy to take a patch for that! unfortunately I have no C programming experience, so i can not patch it. regards Florian 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] Nspawn / getty restart loop
the container-getty@.service only needs to be present, not enabled, you can disable the unit, then the logs go away 2014-12-06 15:49 GMT+01:00 Meech meech...@gmail.com: Running Arch64 / Systemd 217. I have a barebones container initialized with pacstrap. The conatiner is stored in /var/lib and started via systemd (systemctl start systemd-nspawn@mycontainer) When nobody is logged in, the journal is spammed every 10 seconds with agetty errors. How can I prevent this? It seems like it's in a never ending restart loop until somebody is logged in. Dec 06 00:13:53 vpn agetty[1582]: /dev/pts/0: No such file or directory Dec 06 00:14:03 vpn systemd[1]: container-getty@0.service has no holdoff time, scheduling restart. Dec 06 00:14:03 vpn systemd[1]: Stopping Container Getty on /dev/pts/0... Dec 06 00:14:03 vpn systemd[1]: Starting Container Getty on /dev/pts/0... Dec 06 00:14:03 vpn systemd[1]: Started Container Getty on /dev/pts/0. Dec 06 00:14:03 vpn agetty[1583]: /dev/pts/0: No such file or directory Dec 06 00:14:13 vpn systemd[1]: container-getty@0.service has no holdoff time, scheduling restart. Dec 06 00:14:13 vpn systemd[1]: Stopping Container Getty on /dev/pts/0... Dec 06 00:14:13 vpn systemd[1]: Starting Container Getty on /dev/pts/0... Dec 06 00:14:13 vpn systemd[1]: Started Container Getty on /dev/pts/0. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
