4 Replies Latest reply on Nov 11, 2009 3:10 PM by tessebie

    What does "/> init: /bin/dnsmasq respawning too fast" mean

      I posted this question on the SnapGear Group but since you are now moving toward this new site I have also posted this message here.  I have a customer who is using the SG300 Secure Router.  When he connects to the console port on the equipment they are seeing the following messages:

       

      />

      /> init: /bin/dnsmasq respawning too fast

      init: /bin/dnsmasq respawning too fast

      init: /bin/dnsmasq respawning too fast

       

      We are curious what this is telling us and how critical is this message.

       

      Thanks,

       

      progresso89

        • 1. Re: What does "/> init: /bin/dnsmasq respawning too fast" mean

          It mean the internal DNS proxy dnsmasq is dieing and being restarted continually.

           

          This should not occur.

           

          are you running the latest firmware code ?

          • 2. Re: What does "/> init: /bin/dnsmasq respawning too fast" mean

            The customer is at a lower version of the firmware code.  We need to upgrade them but because their unit is in a remote location and will require a remote update we would like to test this at our office first.  But I need to downgrade the firmware code in my box to match what is in theirs.  Is there a way to do this in the SG300?

            • 3. Re: What does "/> init: /bin/dnsmasq respawning too fast" mean

              Use the -i additional parameter to allow downgrades.

               

              be sure to factory erase after a downgrade.

              • 4. Re: What does "/> init: /bin/dnsmasq respawning too fast" mean

                Using '-i' to downgrade, then factory erase, then apply <site-config>, then upgrade is a fine way to test everything.

                 

                There is a chance that the 'respawning too fast' may affect remote firmware downloads. So if your test system does not exhibit the same behavior such that you can verify that it won't affect the upgrade process, you should consider putting a contingency plan in place.

                 

                While doing the whole process is a good idea in this instance, its worth pointing out that configuration migration actually happens when the new firmware boots. Only the new firmware can know about what settings it actually needs to change to fit any new way of 'doing things'.

                 

                It follows that if you are upgrading from X to Y, and all you care about is to check if migration will work fine, then you can just boot up version Y (ie. the new firmware) and 'restore' the configuration from X (as saved from the site in question), then reboot. When the system boots up again, what it will find is that it has version-X configuration in its config-file-system. And it will migrate it - just as if you had just upgraded from X to Y.  Tadaaa....

                 

                This works with all current firmware releases and can save quite a bit of time and hassle.

                 

                Cheers

                tom