[Bug 1576341] Re: fails in lxd container

Did some digging on the mlockall failure: /* we don't want our active sessions to be paged out... */ if (mlockall(MCL_CURRENT | MCL_FUTURE)) { log_error("failed to mlockall, exiting..."); log_close(log_pid); exit(ISCSI_ERR);

[Bug 1576341] Re: fails in lxd container

16.04: $ lxc launch xenial x1 $ lxc file pull x1/etc/cloud/build.info - build_name: server serial: 20160211-034510 $ lxc exec x1 systemctl is-system-running degraded $ lxc exec x1 -- systemctl --state=failed UNIT LOAD ACTIVE SUBDESCRIPTION ● dev-hugepages.mount

[Bug 1576341] Re: fails in lxd container

** Description changed: 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 exc x1 systemctl is-system-running + $ lxc exec x1

[Bug 1576341] Re: fails in lxd container

This bug was fixed in the package open-iscsi - 2.0.873+git0.3b4b4500-14ubuntu14 --- open-iscsi (2.0.873+git0.3b4b4500-14ubuntu14) zesty; urgency=medium * Make systemd job not run in containers (LP: #1576341) -- Serge Hallyn Sun, 15 Jan 2017 23:08:29

[Bug 1576341] Re: fails in lxd container

Seems like just adding ConditionVirtualization=!container to debian//open-iscsi.service should fix it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576341 Title: fails in lxd container To

[Bug 1576341] Re: fails in lxd container

i can also confirm this. i noticed it when an update for open-iscsi came along and i tried to update the container: ... ... ... Setting up open-iscsi (2.0.873+git0.3b4b4500-14ubuntu8.2) ... Job for open-iscsi.service failed because the control process exited with error code. See "systemctl

[Bug 1576341] Re: fails in lxd container

I can confirm this on recently installed system. $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 16.04.1 LTS Release:16.04 Codename: xenial $ lxc launch ubuntu:xenial testct Creating testct Starting testct $ lxc exec testct -- systemctl

[Bug 1576341] Re: fails in lxd container

Any progress with regards to this bug? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576341 Title: fails in lxd container To manage notifications about this bug go to:

[Bug 1576341] Re: fails in lxd container

** Changed in: systemd (Ubuntu) Importance: Undecided => High ** Changed in: open-iscsi (Ubuntu) Importance: Undecided => High ** Changed in: lxd (Ubuntu) Importance: Undecided => High ** Changed in: lvm2 (Ubuntu) Importance: Undecided => High -- You received this bug notification

Re: [Bug 1576341] Re: fails in lxd container

Quoting Martin Pitt (martin.p...@ubuntu.com): > So would a namespace aware check for CAP_SYS_AUDIT say "no" then? (The > audit subsystem isn't namespace aware right now). How would such a check > look like in userspace? I suppose a namespace aware check for CAP_SYS_AUDIT would look like an fcntl

[Bug 1576341] Re: fails in lxd container

So would a namespace aware check for CAP_SYS_AUDIT say "no" then? (The audit subsystem isn't namespace aware right now). How would such a check look like in userspace? CAP_SYS_ADMIN is a different beast, as this contains a lot of different and unrelated issues. It's also not fine-grained enough

[Bug 1576341] Re: fails in lxd container

> systemd-sysctl.service loaded failed failed Apply Kernel Variables I filed this as https://github.com/lxc/lxcfs/issues/111 . I'll stop treating this here now, as there are already too many unrelated issues here for one bug report. -- You received this bug notification because you are a member

[Bug 1576341] Re: fails in lxd container

Right you can check whether you have CAP_X targeted at your own user ns, and you can check whether you are in an init_user_ns (by checking /proc/self/uid_map). The manpages currently are rarely clear, when they say you need CAP_X, about which namespace that must be targeted against. (I just

[Bug 1576341] Re: fails in lxd container

LXC doesn't drop many capabilities, we only really drop mac_admin, mac_override, sys_time, sys_module and sys_rawio. That's because we do run workloads which do need the other capabilities, including cap_sys_admin. Now in an unprivileged container, having those capabilities will only do you

[Bug 1576341] Re: fails in lxd container

I closed the lxd task as our current behavior wrt capabilities is correct. But I also subscribed the ubuntu-lxc team to this bug so we can keep an eye on it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1576341] Re: fails in lxd container

> ● systemd-remount-fs.service loaded failed failed Remount Root and Kernel File Systems Actually, I cannot reproduce this bit. I launched a xenial lxd container with the default lxd config on xenial host, and this unit succeeded. It's also supposed to be a no-op as there are no actual fstab

[Bug 1576341] Re: fails in lxd container

These four units belong to the systemd package itself: > dev-hugepages.mount loaded failed failed Huge Pages File System > systemd-journald-audit.socket loaded failed failed Journal Audit Socket These units attempt to not start in containers with less privileges with

[Bug 1576341] Re: fails in lxd container

** Also affects: lxd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576341 Title: fails in lxd container To manage notifications about this bug

[Bug 1576341] Re: fails in lxd container

Unpriv containers don't have CAP_IPC_LOCK at this time; we need to determine if that's requirement , or if it's actually non-fatal. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1576341 Title:

[Bug 1576341] Re: fails in lxd container

Actually, ooms are non-fatal, but the mlockall is. strace shows: [pid 521] mlockall(MCL_CURRENT|MCL_FUTURE [pid 522] <... getdents resumed> /* 2 entries */, 32768) = 48 [pid 522] getdents(5, /* 0 entries */, 32768) = 0 [pid 522] close(5)= 0 [pid 522] exit_group(0)

[Bug 1576341] Re: fails in lxd container

iscsid.service: Failed to read PID from file /run/iscsid.pid: Invalid argument When runnig iscsid -f -d7, we see the issue: root@x1:~# iscsid -f -d 7 iscsid: sysfs_init: sysfs_path='/sys' iscsid: InitiatorName=iqn.1993-08.org.debian:01:32a765bb043 iscsid: