Ubuntu
lxc package

lxc fails to start on boot but succeeds with a manual boot

Bug #1251352 reported by Tim Spriggs
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lxc (Ubuntu)
Fix Released
High
Unassigned
Saucy
Fix Released
High
Unassigned

Bug Description

=========================================
SRU Justification
1. Impact: containers are autostarted with bad (duplicate) configuration, and/or may fail
2. Devel fix: don't load the original configuration if a custom configuration file is specified
3. Stable fix: same as devel fix
4. Test case:
        sudo lxc-create -t ubuntu -n xxx
        echo "lxc.network.name = eth0" | sudo tee -a /var/lib/lxc/xxx/config
        cp /var/lib/lxc/xxx/config /tmp
        sudo lxc-start -n xxx -f /tmp/config
    This will fail without the fix.
5. Regression potential: there should be no regressions, as we simply avoid loading the container's stock configuration file if an alternate configuration file is specified.
=========================================

root@cps2-c1:/var/log/upstart# cat lxc.log
lxc-instance (os-api-cps2) start/running, process 2880

root@cps2-c1:/var/log/upstart# tail -f lxc-instance-os-api-cps2.log
lxc-start: failed to rename veth3ITMNG->eth0 : File exists
lxc-start: failed to setup netdev
lxc-start: failed to setup the network for 'os-api-cps2'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'os-api-cps2'

root@cps2-c1:/var/log/upstart# cat network-interface-veth3ITMNG.log
ifdown: interface veth3ITMNG not configured

root@cps2-c1:/var/log/upstart# cat /etc/lxc/auto/os-api-cps2
# Template used to create this container: ubuntu
# Template script checksum (SHA-1): 6f468a9a658112f6420fb39d2ab90a80fd43cd22

lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br18
lxc.network.name = eth0
lxc.network.hwaddr = 00:16:3e:00:02:68
lxc.network.ipv6 = **********
lxc.network.mtu = 9000

lxc.rootfs = /var/lib/lxc/os-api-cps2/rootfs
lxc.mount = /var/lib/lxc/os-api-cps2/fstab
lxc.pivotdir = lxc_putold

lxc.devttydir = lxc
lxc.tty = 4
lxc.pts = 1024

lxc.utsname = os-api-cps2
lxc.arch = amd64
lxc.cap.drop = sys_module mac_admin mac_override

# When using LXC with apparmor, uncomment the next line to run unconfined:
#lxc.aa_profile = unconfined

lxc.cgroup.devices.deny = a
# Allow any mknod (but not using the node)
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
#lxc.cgroup.devices.allow = c 4:0 rwm
#lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm
#fuse
lxc.cgroup.devices.allow = c 10:229 rwm
#tun
lxc.cgroup.devices.allow = c 10:200 rwm
#full
lxc.cgroup.devices.allow = c 1:7 rwm
#hpet
lxc.cgroup.devices.allow = c 10:228 rwm
#kvm
lxc.cgroup.devices.allow = c 10:232 rwm

Running "service lxc restart" results in the same errors.

Running "lxc-start -d -n os-api-cps2" from the command line successfully starts the instance.

root@cps2-c1:/var/log/upstart# dpkg -l | grep lxc
ii liblxc0 1.0.0~alpha1-0ubuntu13 amd64 Linux Containers userspace tools (library)
ii lxc 1.0.0~alpha1-0ubuntu13 amd64 Linux Containers userspace tools
ii lxc-templates 1.0.0~alpha1-0ubuntu13 all Linux Containers userspace tools (templates)
ii lxctl 0.3.1+debian-3 all Utility to manage LXC
ii python3-lxc 1.0.0~alpha1-0ubuntu13 amd64 Linux Containers userspace tools (Python 3.x bindings)

See original description
Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1251352] [NEW] lxc fails to start on boot but succeeds with a manual boot

Thanks for reporting this bug. It appears to be a bug in the handling
of the -f argument by lxc-instance.conf

 status: triaged
 importance: high

Changed in lxc (Ubuntu):
importance: Undecided → High
status: New → Triaged
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Indeed if you remove the lxc.name option, the container starts but
with two network interfaces. So lxc is loading two copies of the
configuration file.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Fix applied to upstream git head.

Changed in lxc (Ubuntu):
status: Triaged → Fix Committed
Changed in lxc (Ubuntu Saucy):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lxc - 1.0.0~alpha2-0ubuntu6

---------------
lxc (1.0.0~alpha2-0ubuntu6) trusty; urgency=low

  * d/p/0002-lxc-start-if-we-pass-in-a-config-file-then-don-t-use.patch
    fix lxc-start -with -f option to not use multiple configuration
    files (LP: #1251352)
 -- Serge Hallyn <email address hidden> Thu, 14 Nov 2013 14:19:02 -0600

Changed in lxc (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Tim Spriggs (tims-t) wrote :

Thanks for the quick fix! Unfortunately, something else broke when I pulled that package from the trusty repository. The lxc instance is started but nothing runs. Starting it manually vs on boot produces the same behavior and I only see these two lines when I start manually:

<4>init: console-setup main process (46) terminated with status 1
<30>systemd-udevd[58]: starting version 204

Furthermore, there are only two processes running, rsyslogd and (after a painful dist-upgrade inside the lxc root) systemd-udevd.

Rolling back to 1.0.0~alpha1-0ubuntu13 allows me to start the instance again (albeit manually).

Revision history for this message
Serge Hallyn (serge-hallyn) wrote : Re: [Bug 1251352] Re: lxc fails to start on boot but succeeds with a manual boot

Quoting Tim Spriggs (<email address hidden>):
> Thanks for the quick fix! Unfortunately, something else broke when I
> pulled that package from the trusty repository. The lxc instance is
> started but nothing runs. Starting it manually vs on boot produces the
> same behavior and I only see these two lines when I start manually:
>
> <4>init: console-setup main process (46) terminated with status 1
> <30>systemd-udevd[58]: starting version 204
>
>
> Furthermore, there are only two processes running, rsyslogd and (after a painful dist-upgrade inside the lxc root) systemd-udevd.
>
> Rolling back to 1.0.0~alpha1-0ubuntu13 allows me to start the instance
> again (albeit manually).

Hi,

simply pulling the packages from trusty should not have worked, as they
depend on libseccomp2 which is not available in saucy. Could you tell
us exactly what you installed?

The hang you are seeing now typically happens when the container fstab
specifies something which fails to mount (often refused by apparmor)
so that mountall hangs. Could you please file a new bug for that issue,
specifying exactly how the container was created, what package versions
exactly you are running on what release, and outputfile resulting from

 lxc-start -n containername -l info -o outputfile

Serge Hallyn (serge-hallyn)
description: updated
Revision history for this message
Stéphane Graber (stgraber) wrote : Please test proposed package

Hello Tim, or anyone else affected,

Accepted lxc into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/lxc/1.0.0~alpha1-0ubuntu14 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in lxc (Ubuntu Saucy):
status: Confirmed → Fix Committed
tags: added: verification-needed
Revision history for this message
Tim Spriggs (tims-t) wrote :

Hello Stéphane,

  I downloaded the packages manually, rebooted the node and the lxc containers seem to have started nominally. Thanks for the info!

Serge,

  Thanks again for the quick fix!

Cheers,
-Tim

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package lxc - 1.0.0~alpha1-0ubuntu14

---------------
lxc (1.0.0~alpha1-0ubuntu14) saucy-proposed; urgency=low

  * d/p/0014-lxc-start-if-we-pass-in-a-config-file-then-don-t-use.patch
    fix lxc-start -with -f option to not use multiple configuration
    files (LP: #1251352)
 -- Serge Hallyn <email address hidden> Mon, 18 Nov 2013 10:08:53 -0600

Changed in lxc (Ubuntu Saucy):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

The verification of the Stable Release Update for lxc has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.