dnsmasq needs to trigger mountall rescan of network mounts

And how are you configuring dnsmasq? If you are using the stock Ubuntu desktop, you will have NetworkManager depending on the dnsmasq-base package, and providing a dnsmasq server that guaranteeably starts before NM signals mountall. If you are using dnsmasq some other way - for instance, by not providing any fallback DNS servers to resolvconf that would be usable by the system between the time the network interface comes up and the time dnsmasq starts - then sure, that's not going to work. But that's nota bug in mountall; mountall has no way of knowing that the network isn't really up yet when it's supposed to be. If anything, that would be a bug in the dnsmasq package for not integrating properly with mountall.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

thanks for addressing this problem.

Am Do den 3. Okt 2013 um 0:49 schrieb Steve Langasek:
> And how are you configuring dnsmasq?

Just as a primary DNS server for that node.

> If you are using the stock Ubuntu desktop, you will have
> NetworkManager depending on the dnsmasq-base package, and providing a
> dnsmasq server that guaranteeably starts before NM signals mountall.

Well, I see no sense for dnsmasq to run on a desktop. And I see no sense
for networmanager to run on a server.

> If you are using dnsmasq some other way - for instance, by not
> providing any fallback DNS servers to resolvconf that would be usable
> by the system between the time the network interface comes up and the
> time dnsmasq starts

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.

> - then sure, that's not going to work.

It should as with other DNS servers too that are installed on the system
itself.

> But that's nota bug in mountall; mountall has no way of knowing
> that the network isn't really up yet when it's supposed to be.

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.

Network without a running DNS resolution is not "up"; logically.

> If anything, that would be a bug in the dnsmasq package for not
> integrating properly with mountall.

I do not understand this sentence.

Regards
   Klaus Ethgen
- --
Klaus Ethgen http://www.ethgen.ch/
pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen <email address hidden>
Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGcBAEBCgAGBQJSUrtIAAoJEKZ8CrGAGfasRQwMAIL9FWl68I8imVuESSbJaiP9
H1OS4CX9bvOOhzR1CYWuKSk1vAZIeCwhlZsf4Z0kYMEsq+tc9kgnvY/V0qr/rake
mXRB+2a68iXGMAy5ioUI9yR8RwaN1fHvANIVUFy6HTrjgypJ100PfZ0EatzXwLOT
CUVDs22i2hAHeUOyMoHvy4z0ASh4+sohdnHaSrMisGTO8oE6qQ+RX8dX8KJfKDeu
GMH3wt6zTzqlNDGck54QZ0dCelAdflkRP/Euv1zm3Yp7UTu4gHktsf8SNi+gcWzT
Q5oclI6/efuFKzYpGZH3VxEQ2OKa1rkvdvOBTnOPT3vDmIM8Au5T6ltWM9uKI4yz
TI0w39BIQ5mrJnwTNJMbTyxwpYZCP4ju5i+g3COjsXGRdunkozIPZVeGFd/XY3E/
GQS11hS08/imNl4oTeUahlwfFgEl/5YMelj3kFgQA7G0VwJhJAzdkdOK3MAiNod/
YK1fC1P5mGknVIHmgnUonYOA/nAzl+gSiENqs57w8g==
=PMAV
-----END PGP SIGNATURE-----

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