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

[Vasiliy Molostov]

> 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.

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.

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.

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.

> 
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20120611/86926854/attachment.pgp>