Hello,
I am new to Omnia (2GB) and a bit surprised to see that one core is always running at 100%. The process is /usr/sbin/umdns started by root and it seems to use no RAM at all.
Please, what is umdns and could I reduce its CPU load ? Many thanks
My config is :
Turris Omnia
Turris OS version 5.0.0
|Turris OS branch hbt
Kernel version 4.14.172
See OpenWrt documentation [1]
If not required on your network stop the daemon and disable it from starting at boot time.
Yes, but it still sounds like a bug somewhere.
Thanks guys. I carefully reverted back to 4.0.5 and will reproduce the steps done while upgrading and activating services so I may find where the bug could be. I’d report if I can find it.
Thanks again
A quick note : it seems not to be related to 5.0.0 and already known (https://gitlab.labs.nic.cz/turris/turris-build/commit/0711c2c8f852ba33426aa8ea08692af604085868) but for some reason, it appeared to me after having upgraded.
Nothing more to add. Thanks
The issue been mentioned as supposedly fixed upstream [2]
Bug fixes and improvements
Services: fix a libubox regression in 19.07.1 that caused umdns to stop working (FS#2833)
[2] [OpenWrt Wiki] OpenWrt 19.07.2 - Service Release - 6 March 2020
Turris Omnia. HBK (5.0.0) I am suffering from the same issue. umdns is using 100% cpu.
Workaround for me is to disable umdns /etc/init.d/umdns disable && /etc/init.d/umdns stop. Is it even needed?
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.
[…]
Multicast DNS borrows heavily from the existing DNS protocol, using the existing DNS message structure, name syntax, and resource record types.
If you are deploying a conventional Unicast DNS server on the network, e.g. kresd, it would be redundant since kresd would provide the same functionality.
mDNS can’t serve the normal queries for “global names” anyway. EDIT: to be clear, normal recursive DNS servers like kresd typically do not support the mDNS protocol and functionality… it’s like two distinct protocols that happen to share some properties.
The protocol is clear, but not the functionality, kresd cannot resolve DNS namespace on (private) LAN?
I’m not sure what you mean. It certainly won’t be asking all the devices on LAN for **.local. I expect it’s better to do this on client side anyway, i.e. individual machines running some avahi/bonjour/systemd-resolved.
Meant that with the resolver (DHCP) glue script for dnsmasq (not available for odhcpd on TOS) to assign a DNS suffix to router client’s a basic PTR record is generated that lets kresd resolve private DNS namespace, centrally and unicast on the network. For that it would seem redundant to deploy mDNS on the router.
Ah, perhaps. I was thinking more of applying to service discovery, but I know neither of these well (mDNS, DNS-SD), and I’m not missing them.
umdns gets enabled after updates. And cpu is still 100% used. Is fix going to be released?
For now I am blacklisting in in HBK here: /etc/updater/conf.d/user.lua:
Uninstall("umdns", {priority = 60})
It was fixed since Turris OS 5.0.0 RC5, which was released yesterday.