New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A container created from images:ubuntu/xenial/i386 can't run sudo command #2323

Closed
Inetgate opened this Issue Aug 30, 2016 · 3 comments

Comments

2 participants
@Inetgate

Inetgate commented Aug 30, 2016

Required information

  • Distribution: Ubuntu Server
  • Distribution version: 16.04.1
  • The output of "lxc info" or if that fails:
    Name: ub0001-32
    Architecture: i686
    Created: 2016/08/30 10:54 UTC
    Status: Running
    Type: persistent
    Profiles: default
    Pid: 9444
    Ips:
    eth0: inet 10.211.12.121 vethUB50B3
    eth0: inet6 fe80::216:3eff:fec1:a28 vethUB50B3
    lo: inet 127.0.0.1
    lo: inet6 ::1
    Resources:
    Processes: 9
    Memory usage:
    Memory (current): 10.77MB
    Memory (peak): 15.37MB
    Network usage:
    eth0:
    Bytes received: 922 bytes
    Bytes sent: 1.34kB
    Packets received: 7
    Packets sent: 11
    lo:
    Bytes received: 0 bytes
    Bytes sent: 0 bytes
    Packets received: 0
    Packets sent: 0
    • Kernel version: 4.4.0-36-generic
    • LXC version: 2.0.4
    • LXD version: 2.0.4
    • Storage backend in use: directory

Issue description

sudo command inside 32 bit xenial container fail.

A brief description of what failed or what could be improved.
When I create 64 bit xenial container, which have no issue, but I create 32 bit xenial container, which return error.
I checked both 2GB memory host and 4GB memory host, results of 32 bit containers are same.

Steps to reproduce

  1. Step one: $ lxc launch images:ubuntu/xenial/i386
  2. Step two: $ lxc exec bash
  3. Step three: # sudo -V, which return "sudo: main: unable to allocate memory"

Information to attach

  • any relevant kernel output (dmesg)
  • container log (lxc info NAME --show-log)
  • main daemon log (/var/log/lxd.log)
  • output of the client with --debug
  • output of the daemon with --debug
@stgraber

This comment has been minimized.

Show comment
Hide comment
@stgraber

stgraber Aug 30, 2016

Member

This is related to the libc issue mentioned in #936 and in a number of other LXD issues.

There is some work in progress upstream by @hallyn to sort this out but it may take a while before they actually accept the patch and for it to make it into all distros.

Until then, you can run:

 lxc exec container -- script /dev/null -c bash

Which I've confirmed here was then able to run "sudo -V" properly.

Member

stgraber commented Aug 30, 2016

This is related to the libc issue mentioned in #936 and in a number of other LXD issues.

There is some work in progress upstream by @hallyn to sort this out but it may take a while before they actually accept the patch and for it to make it into all distros.

Until then, you can run:

 lxc exec container -- script /dev/null -c bash

Which I've confirmed here was then able to run "sudo -V" properly.

@stgraber

This comment has been minimized.

Show comment
Hide comment
@stgraber

stgraber Aug 30, 2016

Member

Entering the container over SSH should also work around that particular issue.

Member

stgraber commented Aug 30, 2016

Entering the container over SSH should also work around that particular issue.

@stgraber

This comment has been minimized.

Show comment
Hide comment
@stgraber

stgraber Aug 30, 2016

Member

Closing as this issue is caused by a glibc issue which we're already tracking upstream.

Member

stgraber commented Aug 30, 2016

Closing as this issue is caused by a glibc issue which we're already tracking upstream.

@stgraber stgraber closed this Aug 30, 2016

abma added a commit to spring/spring-lxc that referenced this issue Apr 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment