Skip to content

L
lxc
Switch branch/tag
  1. 12 Feb, 2017 1 commit
    • seccomp: allow x32 guests on amd64 hosts. · 11de80d6
      Adam Borowski authored 
      Without this patch, x32 guests (and no others) worked "natively" with x32
host lxc, but not on regular amd64 hosts.  That was especially problematic
as a number of ioctls such as those needed by netfilter don't work in such
scenarios, thus you want to run amd64 on the host.

With the patch, you can use all three ABIs: i386 x32 amd64 on amd64 hosts.

Despite x32 being little used, there's no reason to deny it by default:
the admin needs to compile their own kernel with CONFIG_X86_X32=y or (on
Debian) boot with syscall.x32=y.  If they've done so, it is a reasonable
assumption they want x32 guests.
Signed-off-by: 's avatarAdam Borowski <kilobyte@angband.pl>
  3. 08 Feb, 2017 4 commits
    • Merge pull request #1424 from brauner/2017-02-08/thomasDOTjaroschATintra2netDOTcom_pty_sigttou · 3a5cb1af
      Stéphane Graber authored 
      lxc_setup_tios(): Ignore SIGTTOU and SIGTTIN signals
    • Merge pull request #1425 from cebe/patch-1 · b93fbd24
      Stéphane Graber authored 
      Make lxc-net return non-zero on failure
    • Make lxc-net return non-zero on failure · 4f4e7141
      Carsten Brandt authored 
      I found that even though the service lxc-net failed to start because I made some wrong configuration
settings the command exists zero.
So systemd reports the status of the service as good even though it failed:

    # service lxc-net status
    ● lxc-net.service - LXC network bridge setup
       Loaded: loaded (/lib/systemd/system/lxc-net.service; enabled)
       Active: active (exited) since Wed 2017-02-08 08:17:32 EST; 21min ago
      Process: 529 ExecStart=/usr/lib/x86_64-linux-gnu/lxc/lxc-net start (code=exited, status=0/SUCCESS)
     Main PID: 529 (code=exited, status=0/SUCCESS)
       CGroup: /system.slice/lxc-net.service

    Feb 08 08:17:30 dvm2 systemd[1]: Starting LXC network bridge setup...
    Feb 08 08:17:32 dvm2 lxc-net[529]: dnsmasq: failed to create listening socket for 10.2.2.1: Address already in use
    Feb 08 08:17:32 dvm2 lxc-net[529]: Failed to setup lxc-net.
    Feb 08 08:17:32 dvm2 systemd[1]: Started LXC network bridge setup.

Adding `exit 1` here makes it exit non-zero to make systemd recognize the failure.
Signed-off-by: 's avatarCarsten Brandt <mail@cebe.cc>
    • lxc_setup_tios(): Ignore SIGTTOU and SIGTTIN signals · 4dc96430
      Thomas Jarosch authored 
      Prevent an endless loop while executing lxc-attach in the background:

The kernel might fire SIGTTOU while an ioctl() in tcsetattr()
is executed. When the ioctl() is resumed and retries,
the signal handler interrupts it again.

We can't configure the TTY to stop sending
the signals in the first place since that
is a modification/write to the TTY already.

Still we clear the TOSTOP flag to prevent further signals.

Command to reproduce the hang:
----------------------------
cat > lxc_hang.sh << EOF
/usr/bin/timeout 5s /usr/bin/lxc-attach -n SOMECONTAINER -- /bin/true
EOF
sh lxc_hang.sh    # hangs
----------------------------
Signed-off-by: 's avatarThomas Jarosch <thomas.jarosch@intra2net.com>
  5. 06 Feb, 2017 2 commits
  7. 02 Feb, 2017 7 commits
  9. 30 Jan, 2017 2 commits
  11. 29 Jan, 2017 3 commits
  13. 28 Jan, 2017 1 commit
  15. 27 Jan, 2017 2 commits
  17. 26 Jan, 2017 2 commits
    • Merge pull request #1392 from cjwatson/start-ephemeral-python32 · 42dc0de4
      Stéphane Graber authored 
      Make lxc-start-ephemeral Python 3.2-compatible
    • Make lxc-start-ephemeral Python 3.2-compatible · e0e34b7e
      Colin Watson authored 
      On Ubuntu 12.04 LTS with Python 3.2, `lxc-start-ephemeral` breaks as
follows:

    Traceback (most recent call last):
      File "/usr/bin/lxc-start-ephemeral", line 371, in attach_as_user
      File "/usr/lib/python3.2/subprocess.py", line 515, in check_output
      File "/usr/lib/python3.2/subprocess.py", line 732, in __init__
    LookupError: unknown encoding: ANSI_X3.4-1968

This is because `universal_newlines=True` causes `subprocess` to use
`io.TextIOWrapper`, and in versions of Python earlier than 3.3 that
fetched the preferred encoding using `locale.getpreferredencoding()`
rather than `locale.getpreferredencoding(False)`, thereby changing the
locale and causing codecs to be reloaded.  However, `attach_as_user`
runs inside the container and thus can't rely on having access to the
same Python standard library on disk.

The workaround is to decode by hand instead, avoiding the temporary
change of locale.
Signed-off-by: 's avatarColin Watson <cjwatson@ubuntu.com>
  19. 21 Jan, 2017 2 commits
  21. 12 Jan, 2017 2 commits
  23. 11 Jan, 2017 2 commits
  25. 07 Jan, 2017 5 commits
  27. 04 Jan, 2017 5 commits