Wanted to level-set (and subscribing pitti and hallyn for their advice): 1) LXD unprivileged containers:
4 services in the Zesty daily are failed at start: 1.a) iscsid.service This is because iscsid needs CAP_IPC_LOCK to run mlockall(). Unprivileged containers end up failing in the host kernel. I believe the right way about this is to make the change hallyn did to open-iscsi.service in iscsid.service and make open-iscsi.service properly depend on iscsid.service. But I also think the change made by hallyn is too broad and means even privileged containers cannot use iscsi, which does not seem to be strictly true. 1.a.1) Proposed solution: http://paste.ubuntu.com/24196051/ Effectively, only run iscsid if not in a user namespace (which is where the capabilities get dropped, aiui). And open-iscsi service adds conditions (adapter from Fedora's service file) to check that nodes are defined (which would imply some configuration has been done) and a session exists (which I think means that /etc/iscsi/iscsid.conf contains node.startup=automatic and iscsid has started up a session therefore). If we are worried about the potential breakage (I need to of course test all this in the various iSCSI configurations), we might consider just making the first change (ConditionVirtualization=!private-users) to both .service files, but I feel like that is mostly a workaround for not being able to express cleanly the dependency between the two services: open-iscsi.service can only run if iscsid.service is running; but if iscsid.service is not running because of a Condition, then open- iscsi.service should not be in a failed state. 1.b) systemd-remount-fs.service z2 systemd-remount-fs[50]: mount: can't find LABEL=cloudimg-rootfs /etc/fstab: LABEL=cloudimg-rootfs / ext4 defaults 0 0 This doesn't really make sense in the context of LXD containers afaict, because they don't have a /dev/disk/by-label necessarily? Also, the / is all configured by LXD in practice, not by how the cloud-image is configured? 1.b.1) Proposed solution, comment out the entry in /etc/fstab in the LXD images. 1.c) lvm2-lvmetad.socket lvm[61]: Daemon lvmetad returned error 104 lvm[61]: WARNING: Failed to connect to lvmetad. Falling back to device scanning. ... lvm2-lvmetad.socket: Trigger limit hit, refusing further activation. But manually running `systemctl start lvm2-lvmetad.socket` at `lxc exec z1 bash`, works. That seems confusing and implies some sort of ordering issue? (Note that confusingly `systemctl restart lvm2-lvmetad.socket` does *not* work.) 1.c.1) I don't have a proposed solution for this. 1.d) systemd-journal-audit.socket I found this older thread: https://lists.freedesktop.org/archives /systemd-devel/2015-May/032113.html on this topic. Specifically, https://lists.freedesktop.org/archives/systemd- devel/2015-May/032126.html. Looking at the socket file, though, I see: ConditionCapability=CAP_AUDIT_READ which I do not believe is the same as CAP_ADMIN_READ. I don't know if the ML post or the change are incorrect, but I did verify that using CAP_ADMIN_READ in the container instead of CAP_AUDIT_READ did correctly conditionalize the socket start, while CAP_AUDIT_READ does not. 1.d.1) Proposed solution: changing the ConditionCapability to CAP_ADMIN_READ. 2) Privileged containers 2.a) systemd-remount-fs.service Same as 1.b) above. 2.b) lvm2-lvmetad.socket Same as 1.c) above. With the changes in 1.a.1, 1.b.1 and 1.d.1: 3) Unpriviled container 3.a) Only 1.c) remains, and after issuing `systemctl start lvm2-lvmetad.socket`, `systemctl status` reports 'running'. 4) Privileged container 4.a) same as 3.a) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1576341 Title: systemd in degraded state on startup in LXD containers Status in lvm2 package in Ubuntu: Confirmed Status in lxd package in Ubuntu: Invalid Status in open-iscsi package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Bug description: The ubuntu:xenial image shows 'degraded' state in lxd on initial boot. $ lxc launch xenial x1 $ sleep 10 $ lxc file pull x1/etc/cloud/build.info - build_name: server serial: 20160420-145324 $ lxc exec x1 systemctl is-system-running degraded $ lxc exec x1 -- systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION ● dev-hugepages.mount loaded failed failed Huge Pages File System ● iscsid.service loaded failed failed iSCSI initiator daemon (iscsid) ● open-iscsi.service loaded failed failed Login to default iSCSI targets ● systemd-remount-fs.service loaded failed failed Remount Root and Kernel File Systems ● systemd-sysctl.service loaded failed failed Apply Kernel Variables ● lvm2-lvmetad.socket loaded failed failed LVM2 metadata daemon socket ● systemd-journald-audit.socket loaded failed failed Journal Audit Socket LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 7 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: open-iscsi 2.0.873+git0.3b4b4500-14ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Thu Apr 28 17:28:04 2016 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) SourcePackage: open-iscsi UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
