[Touch-packages] [Bug 1535840] Re: systemd ignoring /etc/modules due to blacklist
** Also affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1535840 Title: systemd ignoring /etc/modules due to blacklist Status in linux package in Ubuntu: New Status in systemd package in Ubuntu: Opinion Bug description: I tried the daily build of 16.04 32-bit to test out the watchdog daemon code. Usually (Ubuntu 10.04-14.04) I add the watchdog module in /etc/modules so it is loaded at boot-time, as watchdog timer modules are not normally auto-loaded due to the risk of an unexpected reboot. However I now find that systemd is choosing to ignore my command to load the module in /etc/modules since it appears in the watchdog blacklist. Typical syslog entries look like this: Jan 19 16:46:14 ubuntu systemd-modules-load[337]: Module 'softdog' is blacklisted Jan 19 17:53:23 ubuntu systemd-modules-load[342]: Module 'softdog' is blacklisted This is just dumb! I have explicitly told the system to load the module, an action that works perfectly well using modprobe or by adding it to the start script for the watchdog, and yet systemd chooses to override that because of the blacklist for auto-loaded modules (in this case in /etc/modprobe.d/blacklist-watchdog.conf). $ lsb_release -rd Description: Ubuntu Xenial Xerus (development branch) Release: 16.04 $ apt-cache policy systemd systemd: Installed: 228-4ubuntu1 Candidate: 228-4ubuntu1 Version table: *** 228-4ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status What I expect to happen is modules added to /etc/modules are loaded at boot time, and not subject to the blacklist for hardware detect / automatic loading. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535840/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1535840] Re: systemd ignoring /etc/modules due to blacklist
Confirmed this still exists in 22.04 (Jammy Jellyfish), with symptoms being SystemD booting always into "degraded" state because wdmd.service (Watchdog Multiplexing Daemon) will always fail due to missing watchdog kernel module(s). Check this is the case with: sudo systemctl status sudo systemctl list-units --failed The solution suggested by @ishworgurung works to allow iTCO_wdt (and other watchdogs) to be loaded by the kernel during boot appropriately. Then, wdmd.service starts up successfully and SystemD enters successful "running" state (assuming all other SystemD services are working properly). However, every kernel package update will place another blacklist file in /lib/modprobe.d/blacklist_linux_$(uname -r).conf. So this is only a temporary workaround until these modules are not blacklisted by default. The blacklist files are part of linux-modules-$(uname -r) package(s). Therefore, this bug should be listed as also affecting Linux kernel source packages for Ubuntu. $ dpkg -S /lib/modprobe.d/blacklist_linux_*.conf linux-modules-5.15.0-74-generic: /lib/modprobe.d/blacklist_linux_5.15.0-74-generic.conf linux-modules-5.4.0-149-generic: /lib/modprobe.d/blacklist_linux_5.4.0-149-generic.conf # ^^ These packages own /lib/modprobe.d/blacklist_linux*.conf files $ apt-cache show linux-modules-$(uname -r) | grep -C5 Source: | sed -e 's/^//' Package: linux-modules-5.15.0-74-generic Architecture: amd64 Version: 5.15.0-74.81 Priority: optional Section: kernel Source: linux Origin: Ubuntu Maintainer: Ubuntu Kernel Team Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 123864 Depends: linux-image-5.15.0-74-generic | linux-image-unsigned-5.15.0-74-generic ## ^^ Part of Linux APT package(s) in Ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1535840 Title: systemd ignoring /etc/modules due to blacklist Status in systemd package in Ubuntu: Opinion Bug description: I tried the daily build of 16.04 32-bit to test out the watchdog daemon code. Usually (Ubuntu 10.04-14.04) I add the watchdog module in /etc/modules so it is loaded at boot-time, as watchdog timer modules are not normally auto-loaded due to the risk of an unexpected reboot. However I now find that systemd is choosing to ignore my command to load the module in /etc/modules since it appears in the watchdog blacklist. Typical syslog entries look like this: Jan 19 16:46:14 ubuntu systemd-modules-load[337]: Module 'softdog' is blacklisted Jan 19 17:53:23 ubuntu systemd-modules-load[342]: Module 'softdog' is blacklisted This is just dumb! I have explicitly told the system to load the module, an action that works perfectly well using modprobe or by adding it to the start script for the watchdog, and yet systemd chooses to override that because of the blacklist for auto-loaded modules (in this case in /etc/modprobe.d/blacklist-watchdog.conf). $ lsb_release -rd Description: Ubuntu Xenial Xerus (development branch) Release: 16.04 $ apt-cache policy systemd systemd: Installed: 228-4ubuntu1 Candidate: 228-4ubuntu1 Version table: *** 228-4ubuntu1 500 500 http://us.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status What I expect to happen is modules added to /etc/modules are loaded at boot time, and not subject to the blacklist for hardware detect / automatic loading. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1535840/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1670959] Re: systemd-resolved using 100% CPU
Maybe interesting things to note: 1. When in bad state: - The mentioned ENV var change in /etc/default/dnsmasq and `sudo systemctl restart dnsmasq` immediately resolves the issue 2. When in good state: - Commenting out the ENV var and running `sudo systemctl restart dnsmasq` does not immediately re-cause the issue - After a reboot, the bad state can be observed again (systemd-resolved using 100% of a CPU core) Maybe there is an order of operations thing here? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1670959 Title: systemd-resolved using 100% CPU Status in dnsmasq package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Sometimes systemd-resolved process is using 100% CPU. After a while it changes back to normal. It happens usually after connecting to the (wifi) network, like starting the OS. strace output: sendmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"6\215\201\200\0\1\0\1\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\300\f\0\34\0\1\0\0\10\235\0\20&\6(\0\0024\0Y%L\4\6#f&\214\0\0)\377\326\0\0\0\0\0\0", 81}], msg_controllen=28, [{cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"), ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}], msg_flags=0}, 0) = 81 sendmsg(3, {msg_name(0)=NULL, msg_iov(4)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=../src/resolve/resolved-dns-stub.c\nCODE_LINE=363\nCODE_FUNCTION=dns_stub_process_query\nSYSLOG_IDENTIFIER=systemd-resolved\n", 160}, {"MESSAGE=", 8}, {"Processing query...", 19}, {"\n", 1}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188 epoll_wait(4, [{EPOLLIN, {u32=3176459184, u64=94565471415216}}], 16, -1) = 1 clock_gettime(CLOCK_BOOTTIME, {44665, 938069872}) = 0 recvfrom(12, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) = 53 recvmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"Z\262\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0", 3936}], msg_controllen=56, [{cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"), ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, {ttl=64}}], msg_flags=0}, 0) = 53 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 getrandom("\365I", 2, GRND_NONBLOCK)= 2 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 getrandom("\203;", 2, GRND_NONBLOCK)= 2 clock_gettime(CLOCK_BOOTTIME, {44665, 938446937}) = 0 open("/run/systemd/netif/links/3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18 connect(18, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 epoll_ctl(4, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=3176610576, u64=94565471566608}}) = 0 write(18, "\203;\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0", 53) = 53 clock_gettime(CLOCK_BOOTTIME, {44665, 938833717}) = 0 clock_gettime(CLOCK_BOOTTIME, {44665, 938875138}) = 0 epoll_ctl(4, EPOLL_CTL_DEL, 18, NULL) = 0 close(18) = 0 journalctl output: Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:41 parsec dnsmasq[1545]: Maximum number of concurrent DNS queries reached (max: 150) As you can see, I would use it together with dnsmasq. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: systemd 232-18ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-9.11-generic 4.10.0 Uname: Linux 4.10.0-9-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 Date: Wed Mar 8 08:20:18 2017 MachineType: Hewlett-Packard HP EliteBook Folio 1020 G1 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/zsh ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.10.0-9-generic root=UUID=a54fe703-35d4-47ac-9c6e-4034421531fb ro
[Touch-packages] [Bug 1670959] Re: systemd-resolved using 100% CPU
Christian: I've tried as I believe you have asked. When in the bad case (I comment out the line: DNSMASQ_EXCEPT=lo and then reboot): - Running this did not resolve the issue: `sudo resolvconf -a lo.dnsmasq` - Running this did not resolve the issue: `echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.dnsmasq` So far only the DNSMASQ_EXCEPT=lo line in /etc/default/dnsmasq appears to resolve the issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1670959 Title: systemd-resolved using 100% CPU Status in dnsmasq package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Sometimes systemd-resolved process is using 100% CPU. After a while it changes back to normal. It happens usually after connecting to the (wifi) network, like starting the OS. strace output: sendmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"6\215\201\200\0\1\0\1\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\300\f\0\34\0\1\0\0\10\235\0\20&\6(\0\0024\0Y%L\4\6#f&\214\0\0)\377\326\0\0\0\0\0\0", 81}], msg_controllen=28, [{cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"), ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}], msg_flags=0}, 0) = 81 sendmsg(3, {msg_name(0)=NULL, msg_iov(4)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=../src/resolve/resolved-dns-stub.c\nCODE_LINE=363\nCODE_FUNCTION=dns_stub_process_query\nSYSLOG_IDENTIFIER=systemd-resolved\n", 160}, {"MESSAGE=", 8}, {"Processing query...", 19}, {"\n", 1}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188 epoll_wait(4, [{EPOLLIN, {u32=3176459184, u64=94565471415216}}], 16, -1) = 1 clock_gettime(CLOCK_BOOTTIME, {44665, 938069872}) = 0 recvfrom(12, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) = 53 recvmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"Z\262\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0", 3936}], msg_controllen=56, [{cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"), ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, {ttl=64}}], msg_flags=0}, 0) = 53 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 getrandom("\365I", 2, GRND_NONBLOCK)= 2 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 getrandom("\203;", 2, GRND_NONBLOCK)= 2 clock_gettime(CLOCK_BOOTTIME, {44665, 938446937}) = 0 open("/run/systemd/netif/links/3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18 connect(18, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 epoll_ctl(4, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=3176610576, u64=94565471566608}}) = 0 write(18, "\203;\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0", 53) = 53 clock_gettime(CLOCK_BOOTTIME, {44665, 938833717}) = 0 clock_gettime(CLOCK_BOOTTIME, {44665, 938875138}) = 0 epoll_ctl(4, EPOLL_CTL_DEL, 18, NULL) = 0 close(18) = 0 journalctl output: Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:41 parsec dnsmasq[1545]: Maximum number of concurrent DNS queries reached (max: 150) As you can see, I would use it together with dnsmasq. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: systemd 232-18ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-9.11-generic 4.10.0 Uname: Linux 4.10.0-9-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 Date: Wed Mar 8 08:20:18 2017 MachineType: Hewlett-Packard HP EliteBook Folio 1020 G1 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/zsh ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.10.0-9-generic root=UUID=a54fe703-35d4-47ac-9c6e-4034421531fb ro rootflags=subvol=@ SourcePackage: systemd UpgradeStatus:
[Touch-packages] [Bug 1670959] Re: systemd-resolved using 100% CPU
Also seeing this issue in Ubuntu 17.10 (artful) with: dnsmasq-base 2.78-1 systemd 234-2ubuntu12.1 I can confirm that following https://askubuntu.com/a/968309/ resolves the issue! Steps to fix the issue: Added this line to /etc/default/dnsmasq: DNSMASQ_EXCEPT=lo Then restarting dnsmasq: sudo systemctl daemon-reload sudo systemctl restart dnsmasq No more systemd-resolved taking 99-100% of a CPU core! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1670959 Title: systemd-resolved using 100% CPU Status in dnsmasq package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: Sometimes systemd-resolved process is using 100% CPU. After a while it changes back to normal. It happens usually after connecting to the (wifi) network, like starting the OS. strace output: sendmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"6\215\201\200\0\1\0\1\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\300\f\0\34\0\1\0\0\10\235\0\20&\6(\0\0024\0Y%L\4\6#f&\214\0\0)\377\326\0\0\0\0\0\0", 81}], msg_controllen=28, [{cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"), ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}], msg_flags=0}, 0) = 81 sendmsg(3, {msg_name(0)=NULL, msg_iov(4)=[{"PRIORITY=6\nSYSLOG_FACILITY=3\nCODE_FILE=../src/resolve/resolved-dns-stub.c\nCODE_LINE=363\nCODE_FUNCTION=dns_stub_process_query\nSYSLOG_IDENTIFIER=systemd-resolved\n", 160}, {"MESSAGE=", 8}, {"Processing query...", 19}, {"\n", 1}], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 188 epoll_wait(4, [{EPOLLIN, {u32=3176459184, u64=94565471415216}}], 16, -1) = 1 clock_gettime(CLOCK_BOOTTIME, {44665, 938069872}) = 0 recvfrom(12, NULL, 0, MSG_PEEK|MSG_TRUNC, NULL, NULL) = 53 recvmsg(12, {msg_name(16)={sa_family=AF_INET, sin_port=htons(33589), sin_addr=inet_addr("127.0.0.1")}, msg_iov(1)=[{"Z\262\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0", 3936}], msg_controllen=56, [{cmsg_len=28, cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, {ipi_ifindex=if_nametoindex("lo"), ipi_spec_dst=inet_addr("127.0.0.53"), ipi_addr=inet_addr("127.0.0.53")}}, {cmsg_len=20, cmsg_level=SOL_IP, cmsg_type=IP_TTL, {ttl=64}}], msg_flags=0}, 0) = 53 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 getrandom("\365I", 2, GRND_NONBLOCK)= 2 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 getrandom("\203;", 2, GRND_NONBLOCK)= 2 clock_gettime(CLOCK_BOOTTIME, {44665, 938446937}) = 0 open("/run/systemd/netif/links/3", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=303, ...}) = 0 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18 connect(18, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 epoll_ctl(4, EPOLL_CTL_ADD, 18, {EPOLLIN, {u32=3176610576, u64=94565471566608}}) = 0 write(18, "\203;\1\20\0\1\0\0\0\0\0\1\4cs41\3wac\vedgecastcdn\3net\0\0\34\0\1\0\0)\2\0\0\0\0\0\0\0", 53) = 53 clock_gettime(CLOCK_BOOTTIME, {44665, 938833717}) = 0 clock_gettime(CLOCK_BOOTTIME, {44665, 938875138}) = 0 epoll_ctl(4, EPOLL_CTL_DEL, 18, NULL) = 0 close(18) = 0 journalctl output: Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:35 parsec systemd-resolved[1512]: Processing query... Mar 08 08:25:41 parsec dnsmasq[1545]: Maximum number of concurrent DNS queries reached (max: 150) As you can see, I would use it together with dnsmasq. ProblemType: Bug DistroRelease: Ubuntu 17.04 Package: systemd 232-18ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-9.11-generic 4.10.0 Uname: Linux 4.10.0-9-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.4-0ubuntu2 Architecture: amd64 Date: Wed Mar 8 08:20:18 2017 MachineType: Hewlett-Packard HP EliteBook Folio 1020 G1 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/zsh ProcKernelCmdLine: BOOT_IMAGE=/@/boot/vmlinuz-4.10.0-9-generic root=UUID=a54fe703-35d4-47ac-9c6e-4034421531fb ro rootflags=subvol=@ SourcePackage: systemd