Ercolino:I can't speak for Simon and the rest of the Dnsmasq team (mostly because I'm not on it) but I
appreciate your discussion and explanation of your need. I would have responded sooner, but I've had a
medical emergency with my wife and was off the net for a few days being with family in the hospital.Now your
comparison to the state of TFTP in my judgement isn't of the same caliber. If the TFTP root is not present
then the only issue is that a handful of netbooting clients wont work at all, and you'll get immediate
feedback (on an impacted system) that you broke something, AND anything that booted on its own will be
fine.If the supplemental config script were to not be present and skipped, you wouldnt get the immediate
feedback that something wasn't working, AND you couldn't guarantee a safe state for the server instance.It
seems to me that you have a legitimate issue, but there are other ways to implement what you need to happen
that don't require changing Dnsmasq at all.1) manipulating the boot order such that Dnsmasq starts AFTER the
USB subsystem is loaded and the supplemental file system is mounted.2) The file system on the embedded device
shouldn't be read-only and you should be able to copy the supplemental config script from the USB key to the
root filesystem of the device and then it would be available when the system booted and your mount sequencing
issue would go away.RanceOn Mar 4, 2022, at 2:52 PM, Ercolino de Spiacico <bellocar...@hotmail.com>
wrote:>How does dnsmasq behave if there is a configuration error in the config >file elsewhere? If the
syntax is broken then it fails hard. Don't see >why this wouldn't be true of a suplemental config script
being referred >to in the main one.And as to --fail-safe: I don't see how this is >reasonable, as it
will lead to undesirable operation and possibly even >broken clients if the mistake includes part of the
dhcp >configuration.Its annoying, but probably better for services not to >start if they can't
interpret/understand their starting statI appreciate the reason why this was originally designed to be the
default behavior however please allow me: this conf-script might be is another beast.I'm on a router
developing this, the dnsmasq config is read at boot from the content of a nvram variable. By the time dnsmasq
starts I must already have this conf-script target created, the USB mounting comes way after everything else
and the script booting process is screwed; NTP doesn't sync, clients don't get an IP... you name it. Also if
the device has no USB this needs to be referenced and created in /tmp (RAM) at boot, this is via the init
script that again is coming in a bit too late in the SoE. Until this file is created dnsmasq fails. Moreover
there's an additional risk here, part of the config content is coming from Internet so outside the
administrative domain. A typo by the list maintainer might cause havoc, most importantly, this is not
necessary when the device is initially set up, it can come after months and affect a large number of devices
at one.I really don't want to sound insistent but let me put it this way, long time ago I brought up this
very topic in the context of TFTP. If the destination folder of TFTP didn't exist it used to fail dnsmasq
(big time on a router). Then fortunately the tftp-no-fail directive was introduced.This conf-script is pretty
much the same case but in a different context. If this extra info here above is still not enough I'll drop
the ball, but I'm just making a final effort because I see value in it, that's
all.Regards_______________________________________________Dnsmasq-discuss mailing
listdnsmasq-disc...@lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
