[Lxc-users] LXC on ubuntu precise and dhclient/net config

Stéphane Graber stgraber at ubuntu.com
Mon Jun 11 18:42:12 UTC 2012


On 06/11/2012 02:32 PM, Vasiliy Molostov wrote:
>  
>> For example, what would you do in the case where isc-dhcp-server depends
>> on an external LDAP server, how can you detect this and how would you
>> check that the LDAP server will indeed work?
>> Also, what would you do if isc-dhcp-server fails to start? just not
>> start lxc? but that'd be wrong in cases where some lxc containers have
>> static IPs or where they are using lxc's own bridge.
> 
> 
> As for me I suspect that isc-dhcp server might depent potentially on start 
> afetr network interface startup, and also after naming services startup. If 
> network interfaces started and naming services are available, then dhcp server 
> can work indeed.
> 
> The lxc service by itself refers not only on network availability (interfaces 
> up and running), but also on naming services, in case of lxc-net it is 
> dnsmasq, and since it might be not only dnsmasq (in cases where lxc-net is 
> disabled) it would be some condition "after naming services started".
> 
> Indeed I mean two possible internal upstart conditions: network-started and 
> naming-services-started. Internally sysv scripts refer some internals in "X-
> Start-before" field in script header and might explain what I mean. Upstart 
> job for dhcpd does not contain these as it was with its sysv startup script in 
> oneiric, so here is the flaw.

Ubuntu never supported the LSB headers, as we don't use insserv. Any
sysvinit job in Ubuntu is considered as "start it whenever you hit the
runlevel", no dependency resolution is being done.

> With these two possible upstart conditions (states) slapd can refer its 
> startup just after network-started, dhcp can refer to start along with naming-
> services-started and lxc can refer to start after naming-services-started. And 
> the  naming-services-started can occur only after network-started, of course.

Here's no such thing as a naming service, in most cases there's not even
a service for that as resolv.conf is directly being read and used by the
libc. Only the desktop machines get a system DNS server started (by
Network Manager) and as all of this depends on specific service
configuration, it's not realistic to expect a start condition to match
all the cases.

> This involve redesign upstart hierarchy in precise, and can lead to careful 
> rewrite/convert other upstart jobs with testing these changes so I can not 
> figure out it in some form of patch or something similar.

Upstart simply doesn't have the features that would be needed for this
and we don't implement new features in released versions of Ubuntu, so
we'll definitely look into minimizing problems for common cases, but I'm
not convinced the case you're describing will fit the conditions.

> As for me, the simplest way is to revert back dhcpd startup code to sysv, 
> (because not all services usual to do dhcp/named/nss things are converted to 
> upstart) or use rc.local to start services in the required workable order.

Well, in your case, you could simply write a /etc/init/lxc.override file
containing:
start on started isc-dhcp-server

Which will override the start condition of lxc to only start once
isc-dhcp-server has been reported as started.

>> Anyway, I had a quick look at the jobs again as I wrote them a while ago
>> and can't say I remember them perfectly. These were indeed proper port
>> of the sysvinit jobs, I don't see any potentially race condition caused
>> by that port that wouldn't have existed before.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20120611/8eb4470c/attachment.pgp>


More information about the lxc-users mailing list