[Bug 1234132] Re: Wrong order for mountall-net
Steve Langasek
steve.langasek at canonical.com
Mon Oct 7 22:23:46 UTC 2013
> Well, I see no sense for dnsmasq to run on a desktop. And I see no sense
> for networmanager to run on a server.
Well, while I agree that networkmanager isn't fit for servers, I don't
think there are many people using dnsmasq on servers this way, either.
> Well, dnsmasq _is_ a DNS server and it is usually the primary one.
> Adding more DNS servers to the resolv.conf makes your server depending
> on systems you do not want them depending on.
You're always dependent on external servers for DNS; in the best case
(which is the case dnsmasq aspires to), you're only dependent on the
root servers and authoritative servers, but dnsmasq itself doesn't
change the fact that there's an external dependency. I could understand
if you said you were running bind, or some other *authoritative*
nameserver for your local network, since that would ensure reliability
in the face of an upstream network outage; but that's not what you're
doing here, so dnsmasq isn't actually providing more reliability than if
you were just pointing at whichever upstream forwarding resolvers you
deem appropriate (proximity vs. high-availability, etc). And in one
concrete fashion, your dnsmasq-only configuration is *less* reliable
than using resolvers on the network, because it adds dnsmasq as a boot
dependency in the rest of the system and the dnsmasq package isn't
handling that boot dependency the way you need it to.
> mountall is a essential part of the system; as is DNS. It is easily
> possible with a normal system-V system to build this dependency. If it
> is not with upstart ... However, I am not a expert of upstart so it
> might be possibly with it too.
Of course it's possible to do that with upstart. The bug is that this
hasn't *been done* for dnsmasq. And this is in no way upstart-specific,
you would have the same race condition with this dnsmasq package on a
sysvinit system; just because you might know how to manually mangle an
init script to get it to start earlier doesn't mean the system is
properly integrated. In fact, the dnsmasq init script declares that it
wants network mounts to be done before it starts, which would cause a
circular dependency for you!
I really don't think the configuration you describe is one that we want
to support, but if we were going to support it, the right way to do this
would be for dnsmasq to integrate with mountall by sending its own
SIGUSR1 once started. dnsmasq does not itself need to be converted to
use an upstart job to do this - it can make the same calls in
/etc/init.d/dnsmasq that are made in /etc/init/mountall-net.conf -
though perhaps it makes sense to convert it to an upstart job rather
than including upstart-specific hooks in the init script.
** Package changed: mountall (Ubuntu) => dnsmasq (Ubuntu)
** Changed in: dnsmasq (Ubuntu)
Status: Incomplete => Triaged
** Summary changed:
- Wrong order for mountall-net
+ dnsmasq needs to trigger mountall rescan of network mounts
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to mountall in Ubuntu.
https://bugs.launchpad.net/bugs/1234132
Title:
dnsmasq needs to trigger mountall rescan of network mounts
Status in “dnsmasq” package in Ubuntu:
Triaged
Bug description:
When using DNS resolving daemons like dnsmasq the mountall-net is done
to early in the boot process when DNS is not available.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1234132/+subscriptions
More information about the foundations-bugs
mailing list