[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


On 6 July 2015 20:04:13 CEST, Simon Kelley <simon at thekelleys.org.uk> wrote:
>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.
>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
>Version: GnuPG v1
>Dnsmasq-discuss mailing list
>Dnsmasq-discuss at lists.thekelleys.org.uk

More information about the Dnsmasq-discuss mailing list