On Wed, 10.02.16 10:56, Daniel J Walsh ([email protected]) wrote: > 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;\
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. > 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; \ 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: https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/ 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. > rm -f /lib/systemd/system/multi-user.target.wants/systemd* > /lib/systemd/system/multi-user.target.wants/getty*;\ What's the rationale for this? First of all, the getty stuff appears entirely unnecessary as [email protected] (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... > sed -i 's/^enable/disable/g' /lib/systemd/system-preset/* Why would this matter? > 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. 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: https://wiki.freedesktop.org/www/Software/systemd/ContainerInterface/ nspawn implements all of this, and docker really should too... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
