Workaround (update)

A quick workaround is to stop the job through brew services stop dnsmasq. Then you should first unload the launchd configuration file and then reload it.

$ sudo launchctl unload -w /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
$ sudo launchctl load -w /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

I found this solution in this article Brew install dnsmasq in macOS Sierra.

Now you can test dnsmasq response both with dig and dscacheutil.

$ dscacheutil -q host -a name fullpipeumbrella.loc
name: fullpipeumbrella.loc
ipv6_address: ::ffff:
ipv6_address: fe80:1::1

name: fullpipeumbrella.loc

$ dig @ fullpipeumbrella.loc

; <<>> DiG 9.8.3-P1 <<>> @ fullpipeumbrella.loc
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10930
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;fullpipeumbrella.loc.      IN  A

fullpipeumbrella.loc.   0   IN  A

;; Query time: 1 msec
;; WHEN: Tue Jun 11 16:56:38 2019
;; MSG SIZE  rcvd: 54

Anyway this should be considered an hack (at least this is my guess), in fact: first of all, there is brew services utility and the software is supposed to be launched by it; second, launchctl man page states clearly that load and unload subcommands are legacy commands. They are still there though from many years. We don't know when Apple will decide to deprecate them and what to give as a replacement.

Subcommands from the previous implementation of launchd are generally
available, though some may be unimplemented. Unimplemented subcommands
are documented as such.

load | unload [-wF] [-S sessiontype] [-D searchpath] paths ...

Another hack to launch the dnsmasq job can be this one (taken from Using Dnsmasq for local development on OS X).

sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq

Though start and stop subcommands are described as development test commands and not production commands and they are legacy subcommands too.

start label
         Start the specified job by label. The expected use of this sub-
         command is for debugging and testing so that one can manually
         kick-start an on-demand server.

stop label
         Stop the specified job by label. If a job is on-demand, launchd
         may immediately restart the job if launchd finds any criteria
         that is satisfied.

The Problem

I installed dnsmasq through Homebrew. Unfortunately it constantly crash and is resumed by launchd through brew services launch script.

This is the log:

Jun 11 10:45:33 MacBook-Pro com.apple.xpc.launchd[1] (homebrew.mxcl.dnsmasq[48386]): Service exited with abnormal code: 2
Jun 11 10:45:33 MacBook-Pro com.apple.xpc.launchd[1] (homebrew.mxcl.dnsmasq): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

I set it up following some tutorials, this is my settings.

#/private/etc/Hosts       localhost broadcasthost
::1             localhost 
fe80::1%lo0     localhost

# [...]               local.web
0:0:0:0:0:ffff:7f00:1   local.web
fe80::1%lo0             local.web               fullpipeumbrella.loc
0:0:0:0:0:ffff:7f00:1   fullpipeumbrella.loc
fe80::1%lo0             fullpipeumbrella.loc

# [...]               localhost.demo1.com
0:0:0:0:0:ffff:7f00:1   localhost.demo1.com
fe80::1%lo0             localhost.demo1.com



This is the output of brew services list:

$ brew services list
Name    Status  User     Plist
dnsmasq started root     /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
httpd   stopped          
php     started username /Users/username/Library/LaunchAgents/homebrew.mxcl.php.plist
php@7.1 stopped          
php@7.2 stopped          

And the output of ps, $ ps -e | grep -v grep | grep dnsmasq:

   65 ??         0:02.31 /usr/local/opt/dnsmasq/sbin/dnsmasq --keep-in-foreground -C /usr/local/etc/dnsmasq.conf

Finally I made a test with dscacheutil:

$ dscacheutil -q host -a name fullpipeumbrella.loc
name: fullpipeumbrella.loc
ipv6_address: ::ffff:
ipv6_address: fe80:1::1

name: fullpipeumbrella.loc

Thanks in advance... :-)

  • I've faced the same issue today, did you find any solution? – Dmytro Jan 11 at 13:48
  • 1
    ok, so I figured out, without sudo dnsmasq can't use port 53, and if you change port value in /usr/local/etc/dnsmasq.confeverything starts working. the port value must be in range from 1024 to 10000 – Dmytro Jan 11 at 17:07

You must log in to answer this question.

Browse other questions tagged .