[Dnsmasq-discuss] dnsmasq segfault

Toke Høiland-Jørgensen toke at toke.dk
Mon Jul 6 21:11:13 BST 2015


I've hit this as well (but not the crash). https://bugs.archlinux.org/task/45485

-Toke

On 6 July 2015 20:04:13 CEST, Simon Kelley <simon at thekelleys.org.uk> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>That works. The wrinkle is that you have to replace /etc/resolv.conf
>with a dangling symlink, rather than using --resolv-file to make
>dnsmasq look in some other place where you put a dangling symlink,
>because the segfault comes from writing to a constant string.
>
>Actually making this work with inotify, rather than generating an
>error in this case, is more difficult. realpath() has unhelpful
>semantics when there's a dangling symlink, and there doesn't seem to
>be an equivalent that follows the the symlinks and tell you where the
>last one points.
>
>Cheers,
>
>Simon.
>
>
>On 06/07/15 14:24, Dave Reisner wrote:
>> On Sun, Jul 05, 2015 at 10:44:24PM +0100, Simon Kelley wrote: This
>> clearly a dnsmasq bug: it shouldn't segfault, but the description 
>> relies of lots of other "stuff" which makes it difficult to work
>> out what systemd is doing to provoke the problem. It there a way to
>> find out how systemd is invoking dnsmasq (ie the command-line) and
>> how it differs between the systemd-resolved stopped and
>> systemd-resolvd started?
>> 
>> 
>> Cheers,
>> 
>> Simon.
>> 
>> 
>>> It should be simple enough to make /etc/resolv.conf a symlink to 
>>> nowhere, and start dnsmasq. Building from git, it produces a
>>> crash where the top frame is:
>> 
>>> #0  inotify_dnsmasq_init () at inotify.c:65 d = 0x55555559b030
>>> "/resolv.conf" path = 0x55555559b02c "/etc/resolv.conf" res =
>>> 0x5555557ae428
>> 
>>> The likely reason /etc/resolv.conf is a symlink to nowhere is
>>> because it points to /run/systemd/resolve/resolv.conf, which is
>>> the real file with the resolver configuration. Ideally, dnsmasq
>>> should wait for the symlink to point to a regular file, or
>>> monitor the target of the symlink for existence. As a stop-gap
>>> measure, users can add an 'After' ordering on 
>>> 'systemd-resolved.service' in dnsmasq.service. I don't consider
>>> this to be a real solution because systemd-resolved is just one
>>> instance of a daemon managing a resolv.conf file on tmpfs, which
>>> /etc/resolv.conf could point to.
>> 
>>> HTH, Dave
>> 
>> 
>> On 05/07/15 20:17, R wrote:
>>>>> dnsmasq segfaults at boot and systemd fails to load the
>>>>> service. ( http://sysv.se/journal.txt ) after the boot
>>>>> process systemd can start dnsmasq successfully through
>>>>> 'systemctl start dnsmasq' and everything works.
>>>>> 
>>>>> This started happening after I switched from using netctl +
>>>>> dhcpcd to configure my interfaces to using systemd-networkd
>>>>> + systemd-resolved.
>>>>> 
>>>>> I was able to reproduce the segfault after the system had
>>>>> started by stopping systemd-resolved. When systemd-resolved
>>>>> was stopped, 'systemctl start dnsmasq' again segfaulted.
>>>>> 
>>>>> Starting systemd-resolved again, systemctl start dnsmasq
>>>>> worked without problems.
>>>>> 
>>>>> I'm using dnsmasq -> dnscrypt_proxy -> opendns on latest Arch
>>>>> Linux fully updated as of the date of this message.
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Dnsmasq-discuss mailing list
>>>>> Dnsmasq-discuss at lists.thekelleys.org.uk 
>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>>>
>>>
>>>
>>>>> 
>_______________________________________________
>>> Dnsmasq-discuss mailing list 
>>> Dnsmasq-discuss at lists.thekelleys.org.uk 
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>> 
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>
>iQIcBAEBCAAGBQJVmsMcAAoJEBXN2mrhkTWiy/gQAIeYEqixdyIdEbhXOS0vtQG3
>BeEf6SquKS7R0ZId7Cf0fM+rZv7VZuy9Ze8k4326/QBfquSwY6qNqpi9v3KvRTRe
>8Qwq9G7kJXowpkQXAyHgdOMAeOwXSG0SGLwPrsbcK5xx6HSVOYwQuf6qLboAbbuH
>0N4Dx8vPvfIGx7D1nP28Z3sJPWJpTCMdU0wdBy+vtM4cPLj2MlZafW7lAvnvIcDe
>FyMntbsWRDoMfjT5O5QUvXdBnAsz+7Vn2Yl/9z6e6xOoENHOId7dxdLyBCSLnOcH
>MX+UUb5EsKUzIl4SZDgWXtdmF2jCWgJ5FPLtyWSt3elsan0SCgJoy/oo2BgzRMRO
>ZefDzEtI5imO4A27q6nqT5U+sZKTdcnef/6pSnBBXOfvSbURJMFdQuYpuUFkzW7H
>Yb95/M7aji9cb+Vs52kLMTzEdsYHiGFlxoTB2ZrCMzTd7o+ptwsThhXyDHTE508q
>uSxQmmdKcf4C7PxMa9iwVXObZ6kNwU8bmzV3bBC7RFMeZTLe6F95mbnp9RUVUyOP
>YixDZ14abLR3yrzIQ9cB2mUPqwG8W8fUqqkYT7x00fZb6ungvSnieRi9RB/npB+x
>UiH58mBKVMmgmqwPFidWYj9p4K5J53Ra5r6MbnLcmBvv/zH4YvNwX9m2Yh+7BbpZ
>GFcph+OaUwudnfBSzQ0k
>=hGIW
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>Dnsmasq-discuss mailing list
>Dnsmasq-discuss at lists.thekelleys.org.uk
>http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss




More information about the Dnsmasq-discuss mailing list