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

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

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
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
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