<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">On 02/10/2016 11:16 AM, Lennart Poettering wrote: </div> <blockquote cite="mid:20160210161639.GA17771@gardel-login" type="cite"> <pre wrap="">On Wed, 10.02.16 10:56, Daniel J Walsh (<a class="moz-txt-link-abbreviated" href="mailto:dwalsh@redhat.com">dwalsh@redhat.com</a>) wrote: </pre> <blockquote type="cite"> <pre wrap="">On Fedora I see a few services starting up and failing when I run systemd, I have been able to disable these by executing. RUN systemctl disable sysinit.target remote-fs.target systemd-remount-fs;\ </pre> </blockquote> <pre wrap=""> sysinit.target and systemd-remount-fs.service are static units; they cannot be enabled via "systemctl enable" or disabled via "systemctl disable". That part should be a NOP and should not have any effect; you can drop it. remote-fs.target has no value either, unless there actually are NFS mounts listed in /etc/fstab. I am pretty sure there aren't any for in your container, are there? Hence, this really sounds like something you can drop too, without any change in behaviour. </pre> <blockquote type="cite"> <pre wrap=""> systemctl mask systemd-firstboot initrd-udevadm-cleanup-db.service systemd-udev-settle.service systemd-udev-trigger.service systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket; \ </pre> </blockquote> <pre wrap=""> The systemd-firstboot service should have no effect unless you actually boot with an empty /etc (or more accuratily: unless you actually boot with an /etc that lacks /etc/machine-id) . Note that it carries a condition ConditionFirstBoot=yes which makes sure that it isn't even executed in normal cases. Masking all the udev stuff is pretty pointless too. These services are conditioned out in containers too anyway. There's really no need to mask them out. More specifically, they contain ConditionPathIsReadWrite=/sys, i.e. are skipped if /sys is read-only, which is the way how container managers should set up /sys (it's a big security hole to allow containers write access to /sys). My recommendation would be to make sure you container manager implements these recommendations: <a class="moz-txt-link-freetext" href="https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/">https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/</a> If your container manager follows these guidelines (of which the /sys being read-only thing is one), then there should be no special hacks necessary in systemd, as it should just work, and detect the slight semantica changes of containers correctly and avoid them cleanly. </pre> <blockquote type="cite"> <pre wrap=""> rm -f /lib/systemd/system/multi-user.target.wants/systemd* /lib/systemd/system/multi-user.target.wants/getty*;\ </pre> </blockquote> <pre wrap=""> What's the rationale for this? First of all, the getty stuff appears entirely unnecessary as <a class="moz-txt-link-abbreviated" href="mailto:getty@.service">getty@.service</a> (which is the only thing generally linked from gettys.target these days) contains ConditionPathExists=/dev/tty0 which means it's already skipped when run on systems lacking a VC (such as containers). And the other services you are removing here: what's the point? they aren't really optional, that's why they are linked from /usr/lib, rather than subject to systemctl enable/disable... </pre> <blockquote type="cite"> <pre wrap=""> sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* </pre> </blockquote> <pre wrap=""> Why would this matter? </pre> <blockquote type="cite"> <pre wrap="">Could someone look at these and tell me if I went too far. I would like to get these commands as the default for systemd in the base RHEL/Fedora and Centos containers. </pre> </blockquote> <pre wrap=""> I don't follow at all. None of this is necessary. systemd works fine in containers as long as the container manager follows these guidelines: <a class="moz-txt-link-freetext" href="https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/">https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/</a> nspawn implements all of this, and docker really should too... Lennart </pre> </blockquote> BTW With the latest code/hooks we now have /sys as readonly /tmp and /run on tmpfs. /etc/machine-id created to match containerid. /var/log/journald/UUID mounted from the host so that journalctl -M UUID will work. Docker containers registered with machinectl. These are the processes run after launching the systemd based container. <pre>system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29042 ? 00:00:00 systemd system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29076 ? 00:00:00 systemd-journal system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29093 ? 00:00:00 dbus-daemon system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29094 ? 00:00:00 httpd system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29099 ? 00:00:00 httpd system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29100 ? 00:00:00 httpd system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29102 ? 00:00:00 httpd system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29104 ? 00:00:00 httpd system_u:system_r:svirt_lxc_net_t:s0:c557,c563 29107 ? 00:00:00 httpd </pre> </body> </html>