[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