[lxc-devel] Upstart job /etc/init/lxc-net.conf doesn't allow re-loading dnsmasq' configuration.

Serge Hallyn serge.hallyn at ubuntu.com
Thu Oct 30 14:32:28 UTC 2014


Quoting Adam Ryczkowski (adam.ryczkowski at statystyka.net):
> Hi,
> 
> There is a subtle bug in the upstart job /etc/init/lxc-net.conf. The
> part that is invoked when you start the service first checks for the
> presence of the lxcbr0 bridge: if it exists it simply exits, without
> touching the dnsmasq deamon. And the part that gets called on
> lxc-net stop doesn't remove the bridge (the bridge may be in use by
> existing containers). tl,dr: issuing sudo service lxc-net restart
> **doesn't reload dnsmasq configuration**.
> 
> This is a major nuisance if you want to assign static IP to the
> containers via dnsmasq.
> 
> ------
> 
> I have contacted Serge Hallyn who is the original author of the
> script on that matter; we both agree that the proper resolution
> would be to split the lxc-net.conf into two jobs: one which prepares
> the bridge, and second that governs the dnsmasq service.
> 
> Is this job already done? Where is the bug tracker? If I submit a
> patch, would someone took a time and inspect it - I have started to
> learn how to use upstart specifically for this task and have exactly
> no experience.
> 
> Yours,

It can be counter-intuitive at times - more so when you just start
out, but upstart can be very elegant.

Upstart is event-based.  Jobs - or instances of jobs - can start when
other jobs are starting, stopping, or sending events.

Looks like we have (at least) two requirements:

1. the lxc-net job should be running so long as the lxc bridge is up
and available.  So we want a lxc-net job the way we have now, where the
bridge is created in pre-start and destroyed on post-stop.  We just
want to yank some of the work out

2. the dnsmasq process on the bridge should be a separate job with
dnsmasq running in the script section.  It should start on 'started
lxc-net' and stop on 'stopping lxc-net'.  If it has a failure, it
should perhaps emit a signal that will stop lxc-net.

3. The firewall rules should probably be a third job, which gets
started either on started lxc-dnsmasq or on started lxc-net, and stopped
symetrically.

So long as we're going this route, we might want to make these jobs
work as instances, so that we can

start lxc-net BRIDGE=lxcbr0
start lxc-net BRIDGE=lxcovs1

and have the same jobs work for all instances.

Stéphane is more versed in upstart jobs than I am, so hopefully he can
sanity check what I'm writing here.

-serge


More information about the lxc-devel mailing list