Bug 76412 - [systemd-nspawn] out of memory and su system errors
Summary: [systemd-nspawn] out of memory and su system errors
Status: RESOLVED FIXED
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-20 19:12 UTC by U. Artie Eoff
Modified: 2014-05-27 22:32 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
strace for first issue (23.72 KB, text/plain)
2014-03-20 19:12 UTC, U. Artie Eoff
Details
strace for second issue (22.99 KB, text/plain)
2014-03-20 19:12 UTC, U. Artie Eoff
Details
strace -s255 -f -o log (83.68 KB, text/plain)
2014-05-27 16:03 UTC, U. Artie Eoff
Details

Description U. Artie Eoff 2014-03-20 19:12:27 UTC
Created attachment 96119 [details]
strace for first issue

I updated to systemd 211 (which should have the fix for bug 75733, if I'm not mistaken) from rawhide on my base Fedora 20 x86_64 OS, then rebooted.  I am now having a few new issues when trying to run commands as a user in a 32-bit (i686) container on an x86_64 host OS.  These issues do not happen if the container is a 64-bit (x86_64) container.

#### Issue 1 ####

Running systemd-nspawn with -u <user> option to execute a command when <user> is part of the "wheel" group in the container.

$ uname -r
  3.13.6-200.fc20.x86_64
$ su -
$ mkdir /srv/mycontainer-i686
$ mkdir -p /srv/mycontainer-i686/etc/yum/vars
$ echo i386 > /srv/mycontainer-i686/etc/yum/vars/basearch
$ echo i686 > /srv/mycontainer-i686/etc/yum/vars/arch
$ yum -y --releasever=20 --nogpg --installroot=/srv/mycontainer-i686 --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal sudo
$ systemd-nspawn -D /srv/mycontainer-i686 adduser jail
$ systemd-nspawn -D /srv/mycontainer-i686 passwd -d jail
$ systemd-nspawn -u jail -D /srv/mycontainer-i686 whoami
  Spawning container mycontainer-i686 on /srv/mycontainer-i686. Press ^] three times within 1s to abort execution.
  jail
$ systemd-nspawn -D /srv/mycontainer-i686 usermod -a -G wheel jail
$ systemd-nspawn -u jail -D /srv/mycontainer-i686 whoami
  Spawning container mycontainer-i686 on /srv/mycontainer-i686. Press ^] three times within 1s to abort execution.
  Out of memory.

  Container mycontainer-i686 failed with error code 1.

#### Issue 2 ####

Running systemd-nspawn as root to execute an "su <user> -c <command>" command.

$ uname -r
  3.13.6-200.fc20.x86_64
$ su -
$ mkdir /srv/mycontainer-i686
$ mkdir -p /srv/mycontainer-i686/etc/yum/vars
$ echo i386 > /srv/mycontainer-i686/etc/yum/vars/basearch
$ echo i686 > /srv/mycontainer-i686/etc/yum/vars/arch
$ yum -y --releasever=20 --nogpg --installroot=/srv/mycontainer-i686 --disablerepo='*' --enablerepo=fedora install systemd passwd yum fedora-release vim-minimal sudo
$ systemd-nspawn -D /srv/mycontainer-i686 adduser jail
$ systemd-nspawn -D /srv/mycontainer-i686 passwd -d jail
$ systemd-nspawn -D /srv/mycontainer-i686 su jail -c whoami
  Spawning container mycontainer-i686 on /srv/mycontainer-i686. Press ^] three times within 1s to abort execution.
  su: System error

  Container mycontainer-i686 failed with error code 1.


I've attached straces for both of the issues if that helps.
Comment 1 U. Artie Eoff 2014-03-20 19:12:52 UTC
Created attachment 96120 [details]
strace for second issue
Comment 2 U. Artie Eoff 2014-03-20 19:33:33 UTC
Ok, so if I add "audit=0" to the kernel command line then I don't encounter Issue 2.  However, I still encounter Issue 1.
Comment 3 Lennart Poettering 2014-05-24 09:17:25 UTC
The second issue is caused by audit being stupid, and needs to be fixed in the kernel, use audit=0 for that, as you found out.

For the first issue, could you please run nspawn through "strace -s255 -f -o log" when this fails, and attach the file it generates here?
Comment 4 U. Artie Eoff 2014-05-27 16:03:57 UTC
Created attachment 99963 [details]
strace -s255 -f -o log
Comment 5 Zbigniew Jedrzejewski-Szmek 2014-05-27 20:52:15 UTC
I'm guessing this:

commit a9dd39d9b482c99da6b3af3a7394b290e2019cb2
Author: Philip Lorenz <philip@bithub.de>
Date:   Wed Apr 9 19:08:45 2014 +0200

    nspawn: Fix erroneous OOM when building group list
    
    change_uid_gid() never initialises sz which may cause greedy_realloc to
    skip the initial buffer allocation.

Can you try with the latest git or with this patch packported (it applies cleanly to v211)?
Comment 6 U. Artie Eoff 2014-05-27 21:09:25 UTC
(In reply to comment #5)
> I'm guessing this:
> 
> commit a9dd39d9b482c99da6b3af3a7394b290e2019cb2
> Author: Philip Lorenz <philip@bithub.de>
> Date:   Wed Apr 9 19:08:45 2014 +0200
> 
>     nspawn: Fix erroneous OOM when building group list
>     
>     change_uid_gid() never initialises sz which may cause greedy_realloc to
>     skip the initial buffer allocation.
> 
> Can you try with the latest git or with this patch packported (it applies
> cleanly to v211)?

This patch is not on master
Comment 7 U. Artie Eoff 2014-05-27 21:24:28 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I'm guessing this:
> > 
> > commit a9dd39d9b482c99da6b3af3a7394b290e2019cb2
> > Author: Philip Lorenz <philip@bithub.de>
> > Date:   Wed Apr 9 19:08:45 2014 +0200
> > 
> >     nspawn: Fix erroneous OOM when building group list
> >     
> >     change_uid_gid() never initialises sz which may cause greedy_realloc to
> >     skip the initial buffer allocation.
> > 
> > Can you try with the latest git or with this patch packported (it applies
> > cleanly to v211)?
> 
> This patch is not on master

Nevermind, I found it... I was searching for the hash initially.
Comment 8 U. Artie Eoff 2014-05-27 21:52:09 UTC
(In reply to comment #5)
> I'm guessing this:
> 
> commit a9dd39d9b482c99da6b3af3a7394b290e2019cb2
> Author: Philip Lorenz <philip@bithub.de>
> Date:   Wed Apr 9 19:08:45 2014 +0200
> 
>     nspawn: Fix erroneous OOM when building group list
>     
>     change_uid_gid() never initialises sz which may cause greedy_realloc to
>     skip the initial buffer allocation.
> 
> Can you try with the latest git or with this patch packported (it applies
> cleanly to v211)?

Hmm... so I actually downloaded the v212 source rpm from Fedora rawhide (systemd-212-5.fc21.src.rpm).  Without backporting the aforementioned patch I recompiled and installed from that source on F20 and now I don't encounter the first issue anymore.  The systemd.spec indicates source is from commit f01de96.
Comment 9 Zbigniew Jedrzejewski-Szmek 2014-05-27 22:32:28 UTC
I can't reproduce this either. valgrind doesn't yield anything useful. Nevertheless, my hypothesis still stands because the error fixed by this patch is compilation dependant, so it is still likely that this is the problem. I'm closing for now, please reopen if you encounter this again.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.