DNS problem - resolv.conf without nameserver

I think this problem happened for a long time (from time to time), but only today I have checked the resolv.conf file and found only 2 lines:

# Generated by Connection Manager
search home

no nameserver lines.

When this problem happens, any Internet access from Kodi fails (obviously, because all are done by DNS names) while home network accesses (SSH, SMB) works, because I use .local names.

While network problem is a probable cause, I belive (as this DNS problem appear only on Vero) that the DHCP client isn’t stable enough to handle the inevitability of network errors.

I don’t want to nail my Vero2 on google d’evil servers (or ISP servers - subject to change) and switch to static IP (or fight to protect resolv.conf from being rewritten).

My quick fix was always to reboot Vero. It is a Windows© method, which I found it more often needed on Linux machines, now, in the presence of the new cool kids like systemd and connman.

The DHCP client should never give up the IP and the DNS servers on any kind of error (DHCP server not responding, full disk, duplicate IP when the server is not responding). Otherwise, the network device will be pushed to coma.

resolv.conf only contains static defined nameservers.

Either you use a static nameserver and configure it there or you use DHCP and the nameserver should be specified in the DHCP response.

From your post it seems you do not want a static setup so there shouldn’t be a static entry.

Is your problem that you are not getting any DNS resolution at all? Or only after some time?

If only after some time then this would almost certainly be a local network issue (possibly too short a lease beinf offered by the DHCP server). We would ned a full set of logs to see why the network drops.

To get a better understanding of the problem you are experiencing we need more information, including logs from you. Our wiki contains detailed steps for providing the relevant info we need to help you.


Not quite. DHCP will populate /etc/resolv.conf unless nodnsproxy is not set in ConnMan. We enable this by default. NetworkManager, standard if.d behaves the same. libc6 consults this file for domain resolution.

This is actually a potential connectivity issue, but obviously logs are needed (from ConnMan). I haven’t seen this problem before. You seem to know what you’re doing on the network side (as you’ve debugged far enough to identify the current problem). Can you let me know if you’re running a custom DHCP server?

Does the issue only begin with renewal of a lease, i.e. if you reboot a few times, do you always get a nameserver?

I’ve checked with the ConnMan team and they’re not presently aware of any recent bugs that would cause this, but we’re a little behind on the ConnMan version. If you can reliably reproduce this I can produce a new ConnMan build for testing

Are you connected via WiFi or Ethernet?



I didn’t know that!

When proxying is enabled, the file is still used but the resolver is set to

Time to go and relearn my linux networking…

We don’t follow the conventional /etc/network/interfaces approach. It makes perfect sense on a Linux desktop or server in a static environment, but doesn’t work for OSMC where users roam and expect to be able to configure things via a GUI.

I know, I learned that the hard way several years ago Sam. There’s an old thread somewhere of me bemoaning connman :slight_smile:

But it seems most systems update resolv.conf which I wasn’t aware of.

Yes, as the GNU libc (libc6) uses this for resolution.

I use the DHCP server of the router ‘rented’ by my ISP.

The Vero2 stays up all the time. I reboot it for upgrades only, without seeing this issue. Tested now with 7 reboots.


I just made the lease time longer in the DHCP server, even if this valid-IP-without-DNS-nameserver case happens for only one machine in my network.

If it will still annoy me, I would monitor the resolv.conf and reinstall a syslog daemon to collect debug info from connmand.

No need to install syslog. OSMC comes already with logging via journalctl

Good to know.

I’ve misinterpreted the output of:

journalctl -u connman.service
No journal files were found.

Now I see that logging is disabled. Which is good :slight_smile:

sudo journalctl -u connman.service


10x again

Logging is obviously activated. What is not activated by default is persistent logging

The persistence, in this case, is simple:

grep nameserver /etc/resolv.conf >/dev/null || journalctl -u connman.service >>/root/connman.log

The systemd stuff is a little more complicated.

Not sure what you are talking about but to enable persistent logging on OSMC you just edit
/etc/systemd/journal.conf and set Storage= persistent.
After next reboot your journal should be in /var/log/journal/ but be aware that this can be a SD card killer.

I got it. Thank you.

I’ve put a hourly timer to save the connman log if nameserver is not present in resolv.conf.
This way I’ll see how often it happens and what connman has to say about that.

Keep us posted


Reproduced faster than expected. See connman log without --debug

I’ve restarted connman with --debug, but next time the log will be big. There is a lot of WiFi scanning.