container-detect.conf should be 'start on virtual-filesystems'

Bug #1047712 reported by Scott Moser
This bug affects 1 person
Affects Status Importance Assigned to Milestone
resolvconf (Ubuntu)
Won't Fix
upstart (Ubuntu)
Won't Fix

Bug Description

I'm running into some issues during my "ephemeral boot" (iscsi read-only root) work for maas.
In debugging bug 1031065, we had 'cloud-init-nonet' actually mount all virtual-filesystems and then emit the event.

After doing that, we were still timing out on networking coming up because of a dependency on specifically 'mounted mountpoint=/run' by container-detect.conf.

changing that to 'start on virtual-filesystems' improves my situation.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: upstart 1.5-0ubuntu8
ProcVersionSignature: User Name 3.5.0-13.14-generic 3.5.3
Uname: Linux 3.5.0-13-generic x86_64
ApportVersion: 2.5.1-0ubuntu7
Architecture: amd64
Date: Sat Sep 8 02:10:46 2012
Ec2AMI: ami-00000148
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
 PATH=(custom, no user)
SourcePackage: upstart
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Scott Moser (smoser) wrote :
description: updated
Revision history for this message
Scott Moser (smoser) wrote :

marked as also-affects resolvconf as /etc/init/resolvconf.conf also is start on mounted MOUNTPOINT=/run

Revision history for this message
Scott Moser (smoser) wrote :

now that i think about it there is a race if we back resolvconf.conf to start on virtual-filesystems.
in that as soon as that event occurs networking could come up before resolvconf has had a chance to prep itself.

Revision history for this message
Scott Moser (smoser) wrote :

one othe rpiece of this puzzle is that /etc/init/iscsi-network-interface.conf is doing some magic to stop the interface from getting bounced.

Revision history for this message
Steve Langasek (vorlon) wrote :

A careful examination of the container-detect job shows that switching it to virtual-filesystems would also result in a race condition. The job has two functions:
 - emitting an event telling whether we're in a container or not
 - populating /run/container_type

The first function is race-free by definition. The second would be racy because the file is consumed by /bin/running-in-container, which is in turn used by /lib/init/apparmor-profile-load, needed by several other upstart jobs to determine whether the apparmor profile needs to be loaded. In the non-container case there's no problem; in the container case, there's a race because these jobs may be started in parallel to the virtual-filesystems processing, check for /run/container_type before it's written, and fail to start because of an apparmor failure.

So unfortunately I don't think we can change this. Instead, this devolves into bug #1031065 / bug #643289, which would also solve this problem once the MOUNTPOINT=/ event was not blocking the MOUNTPOINT=/run event from happening in parallel.

Changed in upstart (Ubuntu):
importance: Undecided → Medium
status: New → Won't Fix
Changed in resolvconf (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers