Re: systemd-resolved floods the logs
On 11/01/2021 03:25, Jerome Lille wrote: On Sun, 2021-01-10 at 15:44 +0800, Ed Greshko wrote: On 06/01/2021 00:10, Jerome Lille wrote: I've just updated a desktop from Fedora 32 to 33 and after that the logs are flooded with the following message systemd-resolved[]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1. systemd-resolved[]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1. This machine uses a VPN service that is always on. The file /etc/resolver.conf has just one line with the nameserver from the VPN provider. There's no problem in name resolution. Just the constant flooding of the logs. Late to the "party". I'm surprised that nobody asked "What kind of VPN are you using, and how did you configure it?". I'm using MullvadVPN with their own client. But I also have a laptop with Fedora 33 and MullvadVPN and it doesn't produce these log messages. The only difference I can think of is that the desktop uses ethernet and the laptop has only wifi. Well, I've only 2 suggestions with regard to this VPN provider. (not knowing anything about it) There rpm download indicates it "Works on Fedora 31+". But that doesn't mean, to me, it has been tested with systemd-resolved when F33 was released. You may want to bring this issue to the attention of supp...@mullvad.net. They also have option to configure a OpenVPN connection. This may integrate better than their client. So, you may want to consider giving that a try. I use OpenVPN with my VPN provider and am satisfied with it. Yes, you have to configure multiple connections to use different access points. But, I only use 4 on a regular basis. So, it wasn't a big deal. --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Sun, 2021-01-10 at 15:44 +0800, Ed Greshko wrote: > On 06/01/2021 00:10, Jerome Lille wrote: > > I've just updated a desktop from Fedora 32 to 33 and after that the > > logs are flooded with the following message > > > > systemd-resolved[]: Using degraded feature set TCP instead of UDP > > for > > DNS server 127.0.0.1. > > systemd-resolved[]: Using degraded feature set UDP instead of TCP > > for > > DNS server 127.0.0.1. > > > > This machine uses a VPN service that is always on. The file > > /etc/resolver.conf has just one line with the nameserver from the > > VPN > > provider. There's no problem in name resolution. Just the constant > > flooding of the logs. > > Late to the "party". > > I'm surprised that nobody asked "What kind of VPN are you using, and > how did you configure it?". I'm using MullvadVPN with their own client. But I also have a laptop with Fedora 33 and MullvadVPN and it doesn't produce these log messages. The only difference I can think of is that the desktop uses ethernet and the laptop has only wifi. /Jerome ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Ed Greshko writes: Networkmanager must be checking if /etc/resolv.conf is a symbolic link and only updating its own private resolver configs, otherwise it'll update them and /etc/resolv.conf I have no idea of what "private configs" you speak. I also can't think of The configs in /var/run/Networkmanager. There's a resolv.conf and a no-stub- resolv.conf in there. why NM would ever check if /etc/resolv.conf was a symlink. Where is that documented? It sure doesn't overwrite it when it's a symlink to systemd's resolver. You removed the symlink, and it happily scribbled over /etc/resolv.conf, so it must be checking that. pgpNrBk4O2k_1.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 10/01/2021 14:50, Ed Greshko wrote: I also can't think of why NM would ever check if /etc/resolv.conf was a symlink. I actually meant to say there would be no need to check if systemd-resolved is masked. But, either way, that was not a very well thought out statement. --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 06/01/2021 00:10, Jerome Lille wrote: I've just updated a desktop from Fedora 32 to 33 and after that the logs are flooded with the following message systemd-resolved[]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1. systemd-resolved[]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1. This machine uses a VPN service that is always on. The file /etc/resolver.conf has just one line with the nameserver from the VPN provider. There's no problem in name resolution. Just the constant flooding of the logs. Late to the "party". I'm surprised that nobody asked "What kind of VPN are you using, and how did you configure it?". I'm running F33 and an OpenVPN connection using the now standard systemd-resolved. The OpenVPN connection was configured and is managed by the normal NetworkManager interface. When the VPN is up the contents of /etc/resolv.conf is not changed. It still has the systemd-resolved info. nameserver 127.0.0.53 options edns0 trust-ad The only thing "new" is in the output of resolvectl. Which now has this added to it. Link 3 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 25.0.0.1 DNS Servers: 25.0.0.1 DNS Domain: ~. So, to me, it seems odd that your /etc/resolv.conf should has been overwritten. --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 10/01/2021 11:04, Tim via users wrote: Ed Greshko: When I tested reverting to the previous behavior I simply started with an empty /etc/resolv.conf. No symlink. No selinux troubles. Everything just worked. Sam Varshavchik: Well, then how do the apps that need to talk to the DNS server find it? Maybe something in the glibc resolver knows to look in the alternate locations if /etc/resolv.conf is empty. Didn't he then go on to say that it was populated? (Letting the system create that configuration file.) Surely his subsequent tests were after that stage. To be specific, I created an empty file by "touch"ing it. Then, on rebott, since systemd-resolved is masked NM will populate the file as it always has. In other words, the previous method of doing name resolution is in effect/restored. But there are apps that read /etc/resolv.conf themselves (Firefox without a proxy?). They'll be hosed now. Surely apps that only look at that file once are always going to have failures. The file changes, things need to make allowances for that. I've no knowledge of firefox reading /etc/resolv.conf directly. As a matter of fact, I don't know of any reason firefox or any other app would do that. Now, since the previous behavior is restored they wouldn't be any less "hosed" than they were in F31. --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 10/01/2021 12:24, Sam Varshavchik wrote: Tim via users writes: Ed Greshko: >> When I tested reverting to the previous behavior I simply started >> with an empty /etc/resolv.conf. >> No symlink. No selinux troubles. Everything just worked. Sam Varshavchik: > Well, then how do the apps that need to talk to the DNS server find > it? Maybe something in the glibc resolver knows to look in the > alternate locations if /etc/resolv.conf is empty. Didn't he then go on to say that it was populated? (Letting the system create that configuration file.) Surely his subsequent tests were after that stage. Didn't see that until later. I'm not in the habit of posting things that I've done that don't work. :-) :-) Networkmanager must be checking if /etc/resolv.conf is a symbolic link and only updating its own private resolver configs, otherwise it'll update them and /etc/resolv.conf I have no idea of what "private configs" you speak. I also can't think of why NM would ever check if /etc/resolv.conf was a symlink. Where is that documented? --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Tim via users writes: Ed Greshko: >> When I tested reverting to the previous behavior I simply started >> with an empty /etc/resolv.conf. >> No symlink. No selinux troubles. Everything just worked. Sam Varshavchik: > Well, then how do the apps that need to talk to the DNS server find > it? Maybe something in the glibc resolver knows to look in the > alternate locations if /etc/resolv.conf is empty. Didn't he then go on to say that it was populated? (Letting the system create that configuration file.) Surely his subsequent tests were after that stage. Didn't see that until later. Networkmanager must be checking if /etc/resolv.conf is a symbolic link and only updating its own private resolver configs, otherwise it'll update them and /etc/resolv.conf Wonder how long this behavior will last. In the olden days I remember that kind of thing being a continual showstopper for a variety of things. Linux seemed to expect a continual and static internet connection and didn't handle dial-up (where you may not be connected most of the day, and your IP was dynamic). NTP, for instance, would try to start (and fail) if you weren't on-line, and never recover. I had to add a NTPd restart script to my connection script. Heck, even doing a graphical login to your computer could be painful if you didn't have an assigned IP. I remember those days and I've done some of these things myself, back then. In general, I would agree that having a transparent DNS proxy on localhost that simply forwards queries to the DNS-server-du-jour is a solid idea. Actually, it's a pretty clever hack. Except that, unsurprisingly, systemd keeps trying to find every possible way to mess it up. It completely fell apart on my server with a bind running on the same machine; systemd somehow found a way to frak it up and have its port 53 proxy start spewing SERVFAILs, for random domains, repeatedly to every client. But sending the same DNS query to bind's port 53 worked as usual. And this wasn't the case of it just sending a TEMPFAIL, or two, or three, but then getting its brains back together and resuming its proxying, quietly. I've tried, over the course of several minutes to see if its brain damage went away. It didn't, it just kept returning SERVFAILs to every query, meanwhile bind, on the same server, was like: "WHASSSUP" And this happened several times, over the course of a week, it wasn't just a one-time fluke. I defy anyone to come up with a logical explanation why systemd-resolved couldn't find bind running on the same machine, and for it to keel over. Not when the real server it always should be talking to is bind on the same machine. Then we have the other reports, with it going nuts with VPN connections, and spewing tons of garbage into syslog …oops, not syslog, journalctl. And then, after reading all those assurances how easy it is turn off this "feature" simply by repointing the /etc/resolv.conf symbolic link (or removing it) – only to discover that its tentacles still slither in, via nsswitch.conf? And then I also read all that jazz about some kind of a overengineered feature-discovery thing it does, for some unclear reason. I'd love to be educated with an explanation of what is that supposed to accomplish. But until then, I just don't trust it. You know, I would've kept quiet and minded my own business, accepting the fact that it's simply a matter of turning off the service, and repointing the symlink. Ok, that sucks but it's not a big deal, not the end of the world, I'll deal with it. But then, discovering this back-door invasion via nsswitch.conf – that ticked me off, somehow. Oh, and about those NTP restart things we were reminiscing about? That was a long time ago. The forward march of progress carries on. Everything seems to be working just fine now, in that area. My laptop keeps connecting and disconnecting from my wifi, as I put it to sleep, and wake up, all the time. chronie seems to be doing its job, keeping its clock in sync. So, I don't really see what this house of cards is giving me, except a headache. pgprVYETpBJ8K.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Ed Greshko: >> When I tested reverting to the previous behavior I simply started >> with an empty /etc/resolv.conf. >> No symlink. No selinux troubles. Everything just worked. Sam Varshavchik: > Well, then how do the apps that need to talk to the DNS server find > it? Maybe something in the glibc resolver knows to look in the > alternate locations if /etc/resolv.conf is empty. Didn't he then go on to say that it was populated? (Letting the system create that configuration file.) Surely his subsequent tests were after that stage. > But there are apps that read /etc/resolv.conf themselves (Firefox > without a proxy?). They'll be hosed now. Surely apps that only look at that file once are always going to have failures. The file changes, things need to make allowances for that. In the olden days I remember that kind of thing being a continual showstopper for a variety of things. Linux seemed to expect a continual and static internet connection and didn't handle dial-up (where you may not be connected most of the day, and your IP was dynamic). NTP, for instance, would try to start (and fail) if you weren't on-line, and never recover. I had to add a NTPd restart script to my connection script. Heck, even doing a graphical login to your computer could be painful if you didn't have an assigned IP. -- uname -rsvp Linux 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Ed Greshko writes: When I tested reverting to the previous behavior I simply started with an empty /etc/resolv.conf. No symlink. No selinux troubles. Everything just worked. Well, then how do the apps that need to talk to the DNS server find it? Maybe something in the glibc resolver knows to look in the alternate locations if /etc/resolv.conf is empty. But there are apps that read /etc/resolv.conf themselves (Firefox without a proxy?). They'll be hosed now. Several years ago there was an issue with the network-online target being broken. Don't recall the exact technical cause, but the end result was that in some cases the network-online target was reached several seconds before, well, local network interfaces were actually configured. So, stuff that was configured to bind to a local IP address failed. It's beginning to come back to me – I think it's when you had static IP addresses, no dhcp, and I'm pretty sure that on one of my servers that are like that, and has sshd- server configured to be bound to an explicit local IP, and it still fails to start immediatley upon boot because the IP address is not configured, and then comes up only 42 seconds later when sshd-server tries again. Anyhow, I was able to implement a workaround by installing a service that was After=NetworkManager-wait-online.service Before=network-online.target and which ran a script that attempted to bind to the local IP address, every second, and terminated only when it succeeded. Well, so far I'm seeing these selinux denials myself, but don't seem to suffer any actual fallout from that. If I ever do, and none of the quick hacks I mentioned will help, I guess I have to write another service that uses inotify to monitor no-stub-resolv.conf, and update /etc/resolv.conf. Or maybe a one-shot service that fixes the selinux context on no-stub- resolv.conf That's life with systemd. pgpHLr9JrRhna.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 10/01/2021 09:17, Ed Greshko wrote: On 10/01/2021 09:12, Sam Varshavchik wrote: Doug H. writes: > > Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to > be fixed. Thanks for opening that bug. Note that my outbound e-mail was being blocked by this. I am using postfix for outbound and the smtp alerts were triggering for each outbound e-mail attempt and were just queuing up until I did "sudo setenforce 0". I verified that new outbound mail was sent after that and I also "pushed" the queue with "postqueue -f" and watched the log as it drained. I might just switch back to the regular setup so that I can have selinux enabled while waiting for the fix to this. If you want to try to fiddle with this: I don't know how NetworkManager writes out no-stub-resolv.conf. If it creates something like 'no-stub-resolv.conf.tmp', writes it out, and then renames it to 'no-stub-resolv.conf' then finding a workaround would be tough. But, if NetworkManager just writes out a new no-stub-resolv.conf, then fiddling the selinux context on the file might make things work again. Until the next update to selinux-policy-targeted, I suppose, which runs a restorecon on the entire universe, and will reset it again. But at least this is something that will only need to be manually unfraked once in a while, until the policies get fixed (hopefully). There is supposedly a way to override local policies and provide site-specific overrides for selinux contexts. Or so I heard. But selinux is very poorly documented, and is very painful to work with, and I never investigated this in the past. When I tested reverting to the previous behavior I simply started with an empty /etc/resolv.conf. No symlink. No selinux troubles. Everything just worked. Just to be clear I simply did systemctl mask systemd-resolved.service rm /etc/resolv.conf touch /etc/resolv.conf systemctl reboot And now [egreshko@f33g ~]$ cat /etc/resolv.conf # Generated by NetworkManager search greshko.com nameserver 192.168.122.1 [egreshko@f33g ~]$ ls -Zl /etc/resolv.conf -rw-r--r--. 1 root root system_u:object_r:net_conf_t:s0 74 Jan 10 09:48 /etc/resolv.conf --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 10/01/2021 09:12, Sam Varshavchik wrote: Doug H. writes: > > Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to > be fixed. Thanks for opening that bug. Note that my outbound e-mail was being blocked by this. I am using postfix for outbound and the smtp alerts were triggering for each outbound e-mail attempt and were just queuing up until I did "sudo setenforce 0". I verified that new outbound mail was sent after that and I also "pushed" the queue with "postqueue -f" and watched the log as it drained. I might just switch back to the regular setup so that I can have selinux enabled while waiting for the fix to this. If you want to try to fiddle with this: I don't know how NetworkManager writes out no-stub-resolv.conf. If it creates something like 'no-stub-resolv.conf.tmp', writes it out, and then renames it to 'no-stub-resolv.conf' then finding a workaround would be tough. But, if NetworkManager just writes out a new no-stub-resolv.conf, then fiddling the selinux context on the file might make things work again. Until the next update to selinux-policy-targeted, I suppose, which runs a restorecon on the entire universe, and will reset it again. But at least this is something that will only need to be manually unfraked once in a while, until the policies get fixed (hopefully). There is supposedly a way to override local policies and provide site-specific overrides for selinux contexts. Or so I heard. But selinux is very poorly documented, and is very painful to work with, and I never investigated this in the past. When I tested reverting to the previous behavior I simply started with an empty /etc/resolv.conf. No symlink. No selinux troubles. Everything just worked. --- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Doug H. writes: > > Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to > be fixed. Thanks for opening that bug. Note that my outbound e-mail was being blocked by this. I am using postfix for outbound and the smtp alerts were triggering for each outbound e-mail attempt and were just queuing up until I did "sudo setenforce 0". I verified that new outbound mail was sent after that and I also "pushed" the queue with "postqueue -f" and watched the log as it drained. I might just switch back to the regular setup so that I can have selinux enabled while waiting for the fix to this. If you want to try to fiddle with this: I don't know how NetworkManager writes out no-stub-resolv.conf. If it creates something like 'no-stub- resolv.conf.tmp', writes it out, and then renames it to 'no-stub- resolv.conf' then finding a workaround would be tough. But, if NetworkManager just writes out a new no-stub-resolv.conf, then fiddling the selinux context on the file might make things work again. Until the next update to selinux-policy-targeted, I suppose, which runs a restorecon on the entire universe, and will reset it again. But at least this is something that will only need to be manually unfraked once in a while, until the policies get fixed (hopefully). There is supposedly a way to override local policies and provide site- specific overrides for selinux contexts. Or so I heard. But selinux is very poorly documented, and is very painful to work with, and I never investigated this in the past. pgpwIhTIerqgH.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Wed, Jan 6, 2021, at 4:15 AM, Sam Varshavchik wrote: > Jerome Lille writes: > > > On Tue, 2021-01-05 at 18:10 -0500, Sam Varshavchik wrote: > > > Chris Murphy writes: > > > > > > > On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy > > > > wrote: > > > > > > > > > > Maybe this bug: > > > > > > > > https://github.com/systemd/systemd/issues/13432 > > > > > > "opened this issue on Aug 29, 2019" > > > > > > I would not expect this to be fixed any time soon. The only solution > > > is: > > > > > > systemctl stop systemd-resolved > > > systemctl disable systemd-resolved > > > rm -f /etc/resolv.conf > > > ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf > > > > > > Hopefully, this fix will not stop working in the future, either. > > > > Thanks for the suggestion. With those changes the flooding of the logs > > went away. I can connect to the VPN and name resolution works. > > > > BUT, I got five different SELinux errors instead > > > > rpmdb was denied read access on resolv.conf > > rpcbind was denied name_bind access on port 64866 > > chronyd was denied getattr access on no-stub-resolv.conf > > gnome-shell was denied getattr access on no-stub-resolv.conf > > geoclue was denied getattr access on no-stub-resolv.conf > > Hm, looks like I've been getting some of these selinux errors too, but > haven't noticed it. > > Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to > be fixed. Thanks for opening that bug. Note that my outbound e-mail was being blocked by this. I am using postfix for outbound and the smtp alerts were triggering for each outbound e-mail attempt and were just queuing up until I did "sudo setenforce 0". I verified that new outbound mail was sent after that and I also "pushed" the queue with "postqueue -f" and watched the log as it drained. I might just switch back to the regular setup so that I can have selinux enabled while waiting for the fix to this. -- Doug Herr fedoraproject@wombatz.com ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Michael H. Warfield writes: > What I do is disable systemd-resolved and fix the resolv.conf file > to put back the original and get rid of systemd's symlink. ALSO! Remove the "resolve [!UNAVAIL=return]" stanza for hosts in /etc/nsswitch.conf! That seems to have been part of my problems. This appears to be the default configuration setting. There must be something particular to your setup that makes this a problem, otherwise everyone else would be in the same boat. I have systemd-resolved disabled, too, but I have no issues. So, what in blazes is this thing, I was wondering… Poking around nsswitch.conf documenation, it seems that is translated into loading libnss_whatever, and then crossing your fingers. Ok, I see that I have /usr/lib64/libnss_resolve.so.2 So what is this? $ rpm -q -f /usr/lib64/libnss_resolve.so.2 systemd-libs-246.7-2.fc33.x86_64 Are you fracking kidding me? Now, I don't have a manual page installed, but Google helpfully provided this link: https://man7.org/linux/man-pages/man8/libnss_resolve.so.2.8.html nss-resolve, libnss_resolve.so.2 - Hostname resolution via systemd-resolved.service What the frak is this frak? What exactly is the point of shoving systemd down this backdoor, via nsswitch.conf, after you explicitly give it the boot, by disabling it via systemctl? What is that supposed to accomplish? Now, I have the same exact setup: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns Now, putting together all the pieces of the puzzles: this is saying to resolve hostnames via systemd-resolved, but if it's not available continue, and try hostname and dns resolution. So, in theory, if systemd-resolved is "unavailable" this will be a no-op. My experience seems to suggest that. But in your case nsswitch.conf thinks, for some reason, that systemd- resolved is still in business, but it fails (because you stopped it), so the crap hits the fan. So the remaining question would be why nssswitch reaches the erroneous conclusion that you still have systemd-resolved active. Yes, expunging this from your nsswitch.conf would resolve (pun not intended) the issue for you, but you still have something else happening that makes this necessary. This does not seem necessary for me. pgpUi7PFjIFcm.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, 2021-01-05 at 11:35 -0500, Tom Horsley wrote: > On Tue, 05 Jan 2021 17:10:06 +0100 > Jerome Lille wrote: > > What can be done? > > What I do is disable systemd-resolved and fix the resolv.conf file > to put back the original and get rid of systemd's symlink. ALSO! Remove the "resolve [!UNAVAIL=return]" stanza for hosts in /etc/nsswitch.conf! That seems to have been part of my problems. Regards, Mike -- Michael H. Warfield (AI4NB) | (o) +1 706 850-8773 | m...@wittsend.com /\/\|=mhw=|\/\/ | (c) +1 678 463-0932 | http://www.wittsend.com/mhw/ ARIN whois: MHW9-ARIN | An optimist believes we live in the best of all PGP Key: 0xC0EB9675674627FF | possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Jerome Lille writes: On Tue, 2021-01-05 at 18:10 -0500, Sam Varshavchik wrote: > Chris Murphy writes: > > > On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy > > wrote: > > > > > > Maybe this bug: > > > > https://github.com/systemd/systemd/issues/13432 > > "opened this issue on Aug 29, 2019" > > I would not expect this to be fixed any time soon. The only solution > is: > > systemctl stop systemd-resolved > systemctl disable systemd-resolved > rm -f /etc/resolv.conf > ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf > > Hopefully, this fix will not stop working in the future, either. Thanks for the suggestion. With those changes the flooding of the logs went away. I can connect to the VPN and name resolution works. BUT, I got five different SELinux errors instead rpmdb was denied read access on resolv.conf rpcbind was denied name_bind access on port 64866 chronyd was denied getattr access on no-stub-resolv.conf gnome-shell was denied getattr access on no-stub-resolv.conf geoclue was denied getattr access on no-stub-resolv.conf Hm, looks like I've been getting some of these selinux errors too, but haven't noticed it. Created bug 1913276 to fix no-stub-resolv.conf, the selinux policy needs to be fixed. pgp3mqtDS5el0.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, 2021-01-05 at 18:10 -0500, Sam Varshavchik wrote: > Chris Murphy writes: > > > On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy > > wrote: > > > > > > Maybe this bug: > > > > https://github.com/systemd/systemd/issues/13432 > > "opened this issue on Aug 29, 2019" > > I would not expect this to be fixed any time soon. The only solution > is: > > systemctl stop systemd-resolved > systemctl disable systemd-resolved > rm -f /etc/resolv.conf > ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf > > Hopefully, this fix will not stop working in the future, either. Thanks for the suggestion. With those changes the flooding of the logs went away. I can connect to the VPN and name resolution works. BUT, I got five different SELinux errors instead rpmdb was denied read access on resolv.conf rpcbind was denied name_bind access on port 64866 chronyd was denied getattr access on no-stub-resolv.conf gnome-shell was denied getattr access on no-stub-resolv.conf geoclue was denied getattr access on no-stub-resolv.conf ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
Chris Murphy writes: On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy wrote: > > Maybe this bug: https://github.com/systemd/systemd/issues/13432 "opened this issue on Aug 29, 2019" I would not expect this to be fixed any time soon. The only solution is: systemctl stop systemd-resolved systemctl disable systemd-resolved rm -f /etc/resolv.conf ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf Hopefully, this fix will not stop working in the future, either. pgpDkVyN1QBKM.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, 2021-01-05 at 10:33 -0700, Chris Murphy wrote: > On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy > wrote: > > > > On Tue, Jan 5, 2021 at 9:10 AM Jerome Lille > > wrote: > > > > > > Hi > > > > > > I've just updated a desktop from Fedora 32 to 33 and after that > > > the > > > logs are flooded with the following message > > > > > > systemd-resolved[]: Using degraded feature set TCP instead of UDP > > > for > > > DNS server 127.0.0.1. > > > systemd-resolved[]: Using degraded feature set UDP instead of TCP > > > for > > > DNS server 127.0.0.1. > > > > > > This machine uses a VPN service that is always on. The file > > > /etc/resolver.conf has just one line with the nameserver from the > > > VPN > > > provider. There's no problem in name resolution. Just the > > > constant > > > flooding of the logs. > > > > > > What can be done? > > > > Maybe this bug: > > https://github.com/systemd/systemd/issues/13432 No, a restart of the systemd-resolved doesn't change anything. If I stop it then the flooding goes away and names are resolved as before. Not sure what would happen at bootup if I disable it, if the vpn client would find its server. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, 2021-01-05 at 11:37 -0500, Tim Evans wrote: > On 1/5/21 11:10 AM, Jerome Lille wrote: > > > This machine uses a VPN service that is always on. The file > > /etc/resolver.conf has just one line with the nameserver from the > > VPN > > You do mean /etc/resolv.conf, right? Right ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, Jan 5, 2021 at 10:32 AM Chris Murphy wrote: > > On Tue, Jan 5, 2021 at 9:10 AM Jerome Lille wrote: > > > > Hi > > > > I've just updated a desktop from Fedora 32 to 33 and after that the > > logs are flooded with the following message > > > > systemd-resolved[]: Using degraded feature set TCP instead of UDP for > > DNS server 127.0.0.1. > > systemd-resolved[]: Using degraded feature set UDP instead of TCP for > > DNS server 127.0.0.1. > > > > This machine uses a VPN service that is always on. The file > > /etc/resolver.conf has just one line with the nameserver from the VPN > > provider. There's no problem in name resolution. Just the constant > > flooding of the logs. > > > > What can be done? > > Maybe this bug: https://github.com/systemd/systemd/issues/13432 -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, Jan 5, 2021 at 9:10 AM Jerome Lille wrote: > > Hi > > I've just updated a desktop from Fedora 32 to 33 and after that the > logs are flooded with the following message > > systemd-resolved[]: Using degraded feature set TCP instead of UDP for > DNS server 127.0.0.1. > systemd-resolved[]: Using degraded feature set UDP instead of TCP for > DNS server 127.0.0.1. > > This machine uses a VPN service that is always on. The file > /etc/resolver.conf has just one line with the nameserver from the VPN > provider. There's no problem in name resolution. Just the constant > flooding of the logs. > > What can be done? Maybe this bug: -- Chris Murphy ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On 1/5/21 11:10 AM, Jerome Lille wrote: This machine uses a VPN service that is always on. The file /etc/resolver.conf has just one line with the nameserver from the VPN You do mean /etc/resolv.conf, right? -- Tim Evans | 5 Chestnut Court | Owings Mills, MD 21117 | 443-394-3864 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: systemd-resolved floods the logs
On Tue, 05 Jan 2021 17:10:06 +0100 Jerome Lille wrote: > What can be done? What I do is disable systemd-resolved and fix the resolv.conf file to put back the original and get rid of systemd's symlink. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
systemd-resolved floods the logs
Hi I've just updated a desktop from Fedora 32 to 33 and after that the logs are flooded with the following message systemd-resolved[]: Using degraded feature set TCP instead of UDP for DNS server 127.0.0.1. systemd-resolved[]: Using degraded feature set UDP instead of TCP for DNS server 127.0.0.1. This machine uses a VPN service that is always on. The file /etc/resolver.conf has just one line with the nameserver from the VPN provider. There's no problem in name resolution. Just the constant flooding of the logs. What can be done? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
