[systemd-devel] Systemd 215 cannot start journald 219 inside systemd-nspawn

[Felipe Sateler]

On 15 May 2015 at 07:31, Lennart Poettering <lennart at poettering.net> wrote:
>
> On Sun, 10.05.15 11:20, Felipe Sateler (fsateler at debian.org) wrote:
>
> > Hi,
> >
> > I'm having a problem with a systemd-nspawn'ed container. The guest
> > journal will not start and thus I have no logs.
> >
> > The host is a 215 Debian Jessie system. The guest is a 219 Debian Sid system.
> >
> > The nspawn unit is at http://paste.debian.net/173849/
> > The host journal log for the systemd process is at
> > http://paste.debian.net/173848/
> >
> > Trying to run systemd-journald manually yields the following error:
> >
> > Failed to join audit multicast group: Operation not permitted
>
> Hmm, what kernel version is this?

% uname -a
Linux mercury 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1
(2015-04-24) x86_64 GNU/Linux

> Note that auditing is generally broken with containers. Due to that,
> we ask users to either disable it completely on the kernel command
> line via audit=0. (see README for details) Optionally, on x86-64 (but
> nox i386) we try to work around this by making audit netlink sockets
> unavailable in containers via seccomp.

Indeed, on the host:

% systemd --version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ
-SECCOMP -APPARMOR

The debian 219 version still has it disabled:

% systemd --version
systemd 219
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS
+KMOD -IDN

It looks like this should be enabled where supported
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760299)

>
> You appear to be using a systemd version without seccomp compiled in,
> hence you won't get the container behaviour described, and you need to
> disable audit in the kernel instead.


So, to make sure I understood correctly: does this have anything to do
with 215/219 interop or is just that 219 wants to use audit and it is
broken? I gather it is the latter but confirmation would be nice. In
other words, would running 219 in the host fix anything, or should we
expect all Debian 219 containers to fail?


-- 

Saludos,
Felipe Sateler