[Bug 1576341] Re: fails in lxd container

[Nish Aravamudan]

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);
}

so I think it's a real issue for iscsid (and I'm not sure we want to
debug random failures in the code if it can't ensure it's 'active
sessions') don't stay in memory.


That change, fwiw, was originally introduced in 2005:

https://github.com/open-iscsi/open-
iscsi/commit/6f37c861162157f4a6e28c2fa3cf50e61726c8f3

so it's unlikely to have been tested anytime recently without 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 manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Nish Aravamudan]

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  loaded failed failed Huge Pages File System
● iscsid.service   loaded failed failed iSCSI initiator daemon (iscs
● systemd-remount-fs.service   loaded failed failed Remount Root and Kernel File
● 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

16.10:

$ lxc launch ubuntu:yakkety y1
$ lxc file pull y1/etc/cloud/build.info -
build_name: server
serial: 20170307
$ lxc exec y1 systemctl is-system-running
degraded
$ lxc exec y1 -- systemctl --state=failed
  UNIT LOAD   ACTIVE SUBDESCRIPTION
● dev-hugepages.mount  loaded failed failed Huge Pages File System
● iscsid.service   loaded failed failed iSCSI initiator daemon (iscs
● open-iscsi.service   loaded failed failed Login to default iSCSI targe
● systemd-remount-fs.service   loaded failed failed Remount Root and Kernel File
● 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

17.04:

$ lxc launch ubuntu-daily:zesty z1
$ lxc file pull z1/etc/cloud/build.info -
build_name: server
serial: 20170315.1
$ lxc exec z1 systemctl is-system-running
degraded
$ lxc exec enormous-quetzal -- systemctl --state=failed
  UNIT  LOAD   ACTIVE SUBDESCRIPTION
 
● iscsid.serviceloaded failed failed iSCSI initiator daemon 
(iscsid) 
● systemd-remount-fs.serviceloaded failed failed Remount Root and Kernel 
File Systems
● 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.

4 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

$ lxc exec enormous-quetzal apt policy open-iscsi
open-iscsi:
  Installed: 2.0.873+git0.3b4b4500-14ubuntu17

So things are better generally. I'm not sure if this is high enough
priority where we might want to consider SRUing some of the changes back
to 16.04?

--

Also, Serge, I was looking at your change from c#17 -- does that mean
even privileged containers would no longer get their iSCSI devices to
start? (iscsiadm mentions that iscsid is often needed) And shouldn't we
do the same (to be consistent) for iscsid.service? Actually, it seems
like if we had done it in iscsid.service, the following:

ExecStartPre=/bin/systemctl --quiet is-active iscsid.service

from open-iscsi.service would have avoided needing to change open-
iscsi.service at all?

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Nish Aravamudan]

** 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 systemctl is-system-running
  degraded
  
  $ lxc exec x1 systemctl --state=failed
    UNIT  LOAD   ACTIVE SUBDESCRIPTION
  ● dev-hugepages.mount   loaded failed failed Huge Pages File System
  ● iscsid.serviceloaded failed failed iSCSI initiator daemon 
(iscsid)
  ● open-iscsi.serviceloaded failed failed Login to default iSCSI 
targets
  ● systemd-remount-fs.serviceloaded failed failed Remount Root and Kernel 
File Systems
  ● systemd-sysctl.serviceloaded 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)

** 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 exec x1 systemctl is-system-running
  degraded
  
- $ lxc exec x1 systemctl --state=failed
+ $ lxc exec x1 -- systemctl --state=failed
    UNIT  LOAD   ACTIVE SUBDESCRIPTION
  ● dev-hugepages.mount   loaded failed failed Huge Pages File System
  ● iscsid.serviceloaded failed failed iSCSI initiator daemon 
(iscsid)
  ● open-iscsi.serviceloaded failed failed Login to default iSCSI 
targets
  ● systemd-remount-fs.serviceloaded failed failed Remount Root and Kernel 
File Systems
  ● systemd-sysctl.serviceloaded 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)

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Launchpad Bug Tracker]

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
-0600

** Changed in: open-iscsi (Ubuntu)
   Status: Confirmed => Fix Released

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Serge Hallyn]

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 manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Hamy]

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 status open-iscsi.service" and "journalctl -xe" for details.
invoke-rc.d: initscript open-iscsi, action "start" failed.
● open-iscsi.service - Login to default iSCSI targets
   Loaded: loaded (/lib/systemd/system/open-iscsi.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2017-01-13 11:35:10 UTC; 16ms 
ago
 Docs: man:iscsiadm(8)
   man:iscsid(8)
  Process: 4334 ExecStartPre=/bin/systemctl --quiet is-active iscsid.service 
(code=exited, status=3)

Jan 13 11:35:10 testi systemd[1]: open-iscsi.service: Failed to reset 
devices.list: Operation not permitted
Jan 13 11:35:10 testi systemd[1]: Starting Login to default iSCSI targets...
Jan 13 11:35:10 testi systemd[1]: open-iscsi.service: Control process exited, 
code=exited status=3
Jan 13 11:35:10 testi systemd[1]: Failed to start Login to default iSCSI 
targets.
Jan 13 11:35:10 testi systemd[1]: open-iscsi.service: Unit entered failed state.
Jan 13 11:35:10 testi systemd[1]: open-iscsi.service: Failed with result 
'exit-code'.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Luis Felipe Marzagao]

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 --state=failed
  UNIT  LOAD   ACTIVE SUBDESCRIPTION
● dev-hugepages.mount   loaded failed failed Huge Pages File System
● iscsid.serviceloaded failed failed iSCSI initiator daemon 
(iscsid)
● open-iscsi.serviceloaded failed failed Login to default iSCSI 
targets
● setvtrgb.service  loaded failed failed Set console scheme
● systemd-remount-fs.serviceloaded failed failed Remount Root and Kernel 
File Systems
● systemd-sysctl.serviceloaded 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.

8 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Akash Chandrashekar]

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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Alberto Salvia Novella]

** 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 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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

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

[Serge Hallyn]

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 or something funky against an nsfs inode for a user namespace.
Going from an instantiated or abstract object (like an fd, a pathname,
a process id) to the relevant nsfs inode would be interesting.  I.e.
if one day we allow unpriv users to mknod /dev/null, then a check
for CAP_MKNOD against /dev/null might return true, while a check for
CAP_MKNOD against /dev/sda might return false.

This is interesting, but not likely to be ever implemented :)

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Martin Pitt]

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 anyway for the
above purpose of "can we mount", as this can't/doesn't consider MACs. So
with the statement above (keeping all caps in a container) this means
that the failing dev-hugepages.mount is not easily fixable. It's also
mostly cosmetical, so not urgent for now. I guess the same goes for
iscsi/lvm2 etc.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Martin Pitt]

> 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 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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Serge Hallyn]

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 corrected one instance in a branch).  And as you can see, if the
manpages were, they woudl be quickly out of date, since the process of
(a) deducing which capability checks can be namespaced, (b) converting
those, or (c) improving the target's namespaces so that the checks can
be namespaced (if possible) is ongoing, and will be for a long time.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Stéphane Graber]

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 
good against resources owned by the container and will (obviously) not let you 
gain any more rights than you had as the owning uid prior to entering the 
container.

So you absolutely do have cap_sys_admin and it will let you do a bunch
of things against the network devices owned by your container or mount
entries owned by the container, ... but it will not let you mess with
things that aren't namespaced and that you wouldn't be allowed to touch
as a normal unprivileged user.

The kernel has a nice ns_capable(ns, CAP) function which lets you check
whether you do have the named capability against a given resource, I'm
not aware of a userspace equivalent though.

Having us drop a bunch of capabilities is the wrong answer though and we
won't be doing that.

** Changed in: lxd (Ubuntu)
   Status: New => Invalid

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Stéphane Graber]

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.
https://bugs.launchpad.net/bugs/1576341

Title:
  fails in lxd container

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Martin Pitt]

> ● 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 entries.
Scott, can you please run

strace /lib/systemd/systemd-remount-fs

in your container and paste the output here? Thanks!

> Adding ConditionPathIsReadWrite=!/ may be the simplest and most
straightforward solution here.

It's actually not. You actually *may* have an fstab, and systemd-
remount-fs is then necessary to (re)mount file  systems with the options
in fstab.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Martin Pitt]

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
ConditionCapability=CAP_SYS_ADMIN and CAP_AUDIT_READ. This does work in
nspawn, but it seems the LXD unprivileged containers pretend to have all
these caps:

Capabilities for `1': =
cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_syslog,cap_wake_alarm,cap_block_suspend,37+ep

Which is misleading. Can we start containers with only those
capabilities which are actually namespace aware and available to the
container, and hide the rest?

> systemd-sysctl.service loaded failed failed Apply Kernel Variables

This is supposed to not start via ConditionPathIsReadWrite=/proc/sys/,
but tries anyway, and with debug logging I get

  systemd-sysctl.service: ConditionPathIsReadWrite=/proc/sys/ succeeded.

This is wrong as both "touch /proc/sys/foo" and "test -w /proc/sys" fail. I'll 
look into this.
 
> systemd-remount-fs.service loaded failed failed Remount Root and Kernel File 
> Systems

This is has "ConditionPathExists=/etc/fstab", but that's true for lxd
containers because they have a dummy /etc/fstab with no entries, just a
comment (thus ConditionFileNotEmpty= would not work either). Checking
for the CAP_SYS_ADMIN capability would be appropriate (which is required
for mounting), but that wouldn't work because of the above issue.

This service does succeed in a container without apparmor restrictions
(--config raw.lxc=lxc.aa_profile=unconfined).

Adding ConditionPathIsReadWrite=!/ may be the simplest and most
straightforward solution here.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Martin Pitt]

** 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 go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Ryan Harper]

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:
  fails in lxd container

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Ryan Harper]

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)   = ?
[pid   521] <... mlockall resumed> )= -1 ENOMEM (Cannot allocate memory)

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1576341] Re: fails in lxd container

[Ryan Harper]

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: InitiatorName=iqn.1993-08.org.debian:01:32a765bb043
iscsid: InitiatorAlias=x1
iscsid: Max file limits 65536 65536

iscsid: Could not increase process priority: Operation not permitted
iscsid: Could not set oom score to -16: Permission denied
iscsid: Could not set oom score to -17: Permission denied
iscsid: failed to mlockall, exiting...

It doesn't handle non-root usernamespace; expects to be able to write to
oom_adjst.  similar to tgtd.

-- 
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:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1576341/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs