Re: [systemd-devel] spurious failures of resolved
If you are using NetworkManager to manage your links, then you need to convince it to stop providing the DNS resolver information. You can't use a systemd-networkd file to override this, as networkd is not managing the links. On Thu, Sep 24, 2020 at 11:10 AM Roman Odaisky wrote: > > Hi, > > > You have "~." for the global config, but your Networkmanager or something > > also sets "~." for each of your two links, so all those settings are back > > to being the same priority again. > > Thanks for shedding some light on this. Is this the intended way network > managers are supposed to interact with systemd or is it a bug in NM? > > If I really want to use a custom DNS server for everything, do I understand > correctly that in addition to Domains=~. I need a network file along the lines > of > > [Match] > Name=* > > [DHCPv4] > UseDNS=no > > ? > > -- > WBR > Roman. > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] spurious failures of resolved
Hi, > You have "~." for the global config, but your Networkmanager or something > also sets "~." for each of your two links, so all those settings are back > to being the same priority again. Thanks for shedding some light on this. Is this the intended way network managers are supposed to interact with systemd or is it a bug in NM? If I really want to use a custom DNS server for everything, do I understand correctly that in addition to Domains=~. I need a network file along the lines of [Match] Name=* [DHCPv4] UseDNS=no ? -- WBR Roman. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] spurious failures of resolved
On Thu, Sep 24, 2020 at 2:45 PM Roman Odaisky wrote: > Hi, > > I have the following resolved configuration: > > [Resolve] > DNS=8.8.8.8 8.8.4.4 > Domains=~. > > and the following resolvectl output: > > Link 76 (usb0) > Current Scopes: DNS > DefaultRoute setting: yes >LLMNR setting: yes > MulticastDNS setting: no > DNSOverTLS setting: no > DNSSEC setting: no > DNSSEC supported: no > Current DNS Server: 192.168.42.129 > DNS Servers: 192.168.42.129 > DNS Domain: ~. > > Link 2 (wlp59s0) > Current Scopes: DNS > DefaultRoute setting: yes >LLMNR setting: yes > MulticastDNS setting: no > DNSOverTLS setting: no > DNSSEC setting: no > DNSSEC supported: no > Current DNS Server: > DNS Servers: > > DNS Domain: ~. > > The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve > resorted to USB tethering). The DNS servers provided by DHCP for that link > use > public IP addresses yet decline to provide services for clients outside > that > ISP, with responses like this: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2800 > ;; QUESTION SECTION: > ;freedesktop.org. IN A > > (note it’s not an NXDOMAIN) > > The second IP address is more honest and sets status: REFUSED. > > This situation results in the following behavior: if I query some domain, > it > always fails for the first time then works afterwards. > > $ resolvectl query google.com.uy > google.com.uy: resolve call failed: 'google.com.uy' does not have any RR > of > the requested type > > $ resolvectl query google.com.uy > google.com.uy: 172.217.169.163 -- link: usb0 > > -- Information acquired via protocol DNS in 5.8ms. > -- Data is authenticated: no > > Did I misconfigure something? Did I misread resolved.conf(5) which states > “Use > the construct "~." to use the system DNS server defined with DNS= > preferably > for all domains”? Is there a bug? > You have "~." for the global config, but your Networkmanager or something also sets "~." for each of your two links, so all those settings are back to being the same priority again. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] portable profile broken file bind mount (/etc/resolv.conf)
On Wed, Sep 23, 2020 at 03:14:45AM -0700, Peter Morrow wrote: > Hi, > > I ran into an issue (v239 custom yocto based distro, though the code is the > same with latest releases) where a portable service ends up with a broken file > bind mount since the file is deleted and recreated on the host. This behaviour > is expected for a file based bind mount, the issue is that the default > portable profile makes use of this pattern when it might be better to bind > mount the parent directory. This would allow changes to be reflected from the > host to the portable service. > > Taking a look at the default portable profile > src/portable/profile/default/service.conf we see: > > BindReadOnlyPaths=/etc/resolv.conf > > /etc/resolv.conf is symlink to /etc/resolv-conf.systemd which is a > symlink to /run/systemd/resolve/resolv.conf. > > The issue comes via src/resolve/resolved.c: > > /* Write finish default resolv.conf to avoid a dangling symlink */ > (void) manager_write_resolv_conf(m); > > The above writes out /run/systemd/resolve/resolv.conf, though obviously > any time manager_write_resolv_conf() is called then > /run/systemd/resolve/resolv.conf is deleted since the file update does > not happen in place: > > manager_write_resolv_conf(): > > if (rename(temp_path_uplink, PRIVATE_UPLINK_RESOLV_CONF) < 0) > r = log_error_errno(errno, "Failed to move new %s into > place: %m", PRIVATE_UPLINK_RESOLV_CONF); > > > This means if the DNS servers are updated after the portable service is > started and the bind mount has completed then we still see the old > version of /run/systemd/resolve/resolv.conf. > > I was thinking that it would be better if the default portable profile > instead had this line in it: > > BindReadOnlyPaths=/run/systemd/resolve/ > > So that if /run/systemd/resolve/resolv.conf is deleted and recreated > then the portable service will see the new version of the file. This > only works since the same heirarchy of symlinks exists in the portable > service image. Is this an OK solution or is it fragile or something > else? I am happy to send a PR to change this if it seems like a workable > solution. I spent some time recreating this on v239 and v246: root@qemux86-64:/run/systemd/resolve# systemctl --version systemd 246 (246.2+) -PAM -AUDIT -SELINUX +IMA -APPARMOR -SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT -GNUTLS +ACL +d root@qemux86-64:/run/systemd/resolve# My findings are as follows: 1) This issue is limited to portable services, I don't see this happening with a normal file bind mount with a "normal" service. 2) I can create the issue on v239 with a test portable service we use, the recreate for v246 is based on the nifty example here: http://0pointer.net/blog/walkthrough-for-portable-services.html root@qemux86-64:~# systemctl status walkthroughd.service --no-pager * walkthroughd.service - A simple example service Loaded: loaded (/etc/systemd/system.attached/walkthroughd.service; enabled; vendor preset: ) Drop-In: /etc/systemd/system.attached/walkthroughd.service.d `-10-profile.conf, 20-portable.conf Active: active (running) since Thu 2020-09-24 13:32:55 UTC; 3min 9s ago Main PID: 251 (walkthroughd) Tasks: 1 (limit: 271) Memory: 3.2M CGroup: /system.slice/walkthroughd.service `-251 /usr/local/lib/walkthroughd/walkthroughd Sep 24 13:32:55 qemux86-64 systemd[1]: Started A simple example service. Sep 24 13:32:56 qemux86-64 walkthroughd[251]: Initializing. root@qemux86-64:~# nsenter -a -t 251 # findmnt | grep resolv |-/etc/resolv.conf tmpfs[/systemd/resolve/resolv.conf] 5 # So this all looks good. To simulate what happens in systemd is /run/systemd/resolve/resolv.conf is to updated C.F.: manager_write_resolv_conf(): if (rename(temp_path_uplink, PRIVATE_UPLINK_RESOLV_CONF) < 0) r = log_error_errno(errno, "Failed to move new %s into place: %m", PRIVATE_UPLINK_RESOLV_CONF); I remove /run/systemd/resolve/resolv.conf and create a new file with the same name but with some other contents. root@qemux86-64:~# cd /run/systemd/resolve/ root@qemux86-64:/run/systemd/resolve# cp resolv.conf /tmp/ root@qemux86-64:/run/systemd/resolve# rm resolv.conf root@qemux86-64:/run/systemd/resolve# echo "Updated file contents" > resolv.conf root@qemux86-64:/run/systemd/resolve# nsenter -a -t 251 # findmnt | grep resolv |-/etc/resolv.conf tmpfs[/systemd/resolve/resolv.conf//deleted] 5 # The mount is marked as deleted and we still see the only file contents: # cat /etc/resolv.conf # This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients # directly to # all known uplink DNS servers. This file lists all configured search # domains. # # Third party programs should typically not access this file directly, # but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) # in a #
Re: [systemd-devel] spurious failures of resolved
On Thursday, 24 September 2020 15:07:12 EEST Kevin P. Fleming wrote: > In your network configuration for the faulty link you can just set > "UseDNS=no" in the 'DHCPv4' section and then resolved will not even > try to use those resolvers. Like most people, I don’t have any systemd network configuration files. Isn’t Domains=~. supposed to be kind of a global UseDNS=no anyway? For the record, my workaround is resolvectl dns wlp59s0 '', but the question is why is it even necessary. -- WBR Roman. > On Thu, Sep 24, 2020 at 7:45 AM Roman Odaisky wrote: > > Hi, > > > > I have the following resolved configuration: > > > > [Resolve] > > DNS=8.8.8.8 8.8.4.4 > > Domains=~. > > > > and the following resolvectl output: > > > > Link 76 (usb0) > > > > Current Scopes: DNS > > > > DefaultRoute setting: yes > > > >LLMNR setting: yes > > > > MulticastDNS setting: no > > > > DNSOverTLS setting: no > > > > DNSSEC setting: no > > > > DNSSEC supported: no > > > > Current DNS Server: 192.168.42.129 > > > > DNS Servers: 192.168.42.129 > > > > DNS Domain: ~. > > > > Link 2 (wlp59s0) > > > > Current Scopes: DNS > > > > DefaultRoute setting: yes > > > >LLMNR setting: yes > > > > MulticastDNS setting: no > > > > DNSOverTLS setting: no > > > > DNSSEC setting: no > > > > DNSSEC supported: no > > > > Current DNS Server: > > > > DNS Servers: > > > > > > > > DNS Domain: ~. > > > > The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve > > resorted to USB tethering). The DNS servers provided by DHCP for that link > > use public IP addresses yet decline to provide services for clients > > outside that ISP, with responses like this: > > > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189 > > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; WARNING: recursion requested but not available > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 2800 > > ;; QUESTION SECTION: > > ;freedesktop.org. IN A > > > > (note it’s not an NXDOMAIN) > > > > The second IP address is more honest and sets status: REFUSED. > > > > This situation results in the following behavior: if I query some domain, > > it always fails for the first time then works afterwards. > > > > $ resolvectl query google.com.uy > > google.com.uy: resolve call failed: 'google.com.uy' does not have any RR > > of > > the requested type > > > > $ resolvectl query google.com.uy > > google.com.uy: 172.217.169.163 -- link: usb0 > > > > -- Information acquired via protocol DNS in 5.8ms. > > -- Data is authenticated: no > > > > Did I misconfigure something? Did I misread resolved.conf(5) which states > > “Use the construct "~." to use the system DNS server defined with DNS= > > preferably for all domains”? Is there a bug? > > > > -- > > TIA > > Roman. > > > > > > ___ > > systemd-devel mailing list > > systemd-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] spurious failures of resolved
In your network configuration for the faulty link you can just set "UseDNS=no" in the 'DHCPv4' section and then resolved will not even try to use those resolvers. On Thu, Sep 24, 2020 at 7:45 AM Roman Odaisky wrote: > > Hi, > > I have the following resolved configuration: > > [Resolve] > DNS=8.8.8.8 8.8.4.4 > Domains=~. > > and the following resolvectl output: > > Link 76 (usb0) > Current Scopes: DNS > DefaultRoute setting: yes >LLMNR setting: yes > MulticastDNS setting: no > DNSOverTLS setting: no > DNSSEC setting: no > DNSSEC supported: no > Current DNS Server: 192.168.42.129 > DNS Servers: 192.168.42.129 > DNS Domain: ~. > > Link 2 (wlp59s0) > Current Scopes: DNS > DefaultRoute setting: yes >LLMNR setting: yes > MulticastDNS setting: no > DNSOverTLS setting: no > DNSSEC setting: no > DNSSEC supported: no > Current DNS Server: > DNS Servers: > > DNS Domain: ~. > > The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve > resorted to USB tethering). The DNS servers provided by DHCP for that link use > public IP addresses yet decline to provide services for clients outside that > ISP, with responses like this: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189 > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 2800 > ;; QUESTION SECTION: > ;freedesktop.org. IN A > > (note it’s not an NXDOMAIN) > > The second IP address is more honest and sets status: REFUSED. > > This situation results in the following behavior: if I query some domain, it > always fails for the first time then works afterwards. > > $ resolvectl query google.com.uy > google.com.uy: resolve call failed: 'google.com.uy' does not have any RR of > the requested type > > $ resolvectl query google.com.uy > google.com.uy: 172.217.169.163 -- link: usb0 > > -- Information acquired via protocol DNS in 5.8ms. > -- Data is authenticated: no > > Did I misconfigure something? Did I misread resolved.conf(5) which states “Use > the construct "~." to use the system DNS server defined with DNS= preferably > for all domains”? Is there a bug? > > -- > TIA > Roman. > > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] spurious failures of resolved
Hi, I have the following resolved configuration: [Resolve] DNS=8.8.8.8 8.8.4.4 Domains=~. and the following resolvectl output: Link 76 (usb0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: 192.168.42.129 DNS Servers: 192.168.42.129 DNS Domain: ~. Link 2 (wlp59s0) Current Scopes: DNS DefaultRoute setting: yes LLMNR setting: yes MulticastDNS setting: no DNSOverTLS setting: no DNSSEC setting: no DNSSEC supported: no Current DNS Server: DNS Servers: DNS Domain: ~. The default route is via usb0. The wlp59s0 link is faulty (that’s why I’ve resorted to USB tethering). The DNS servers provided by DHCP for that link use public IP addresses yet decline to provide services for clients outside that ISP, with responses like this: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18189 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 2800 ;; QUESTION SECTION: ;freedesktop.org. IN A (note it’s not an NXDOMAIN) The second IP address is more honest and sets status: REFUSED. This situation results in the following behavior: if I query some domain, it always fails for the first time then works afterwards. $ resolvectl query google.com.uy google.com.uy: resolve call failed: 'google.com.uy' does not have any RR of the requested type $ resolvectl query google.com.uy google.com.uy: 172.217.169.163 -- link: usb0 -- Information acquired via protocol DNS in 5.8ms. -- Data is authenticated: no Did I misconfigure something? Did I misread resolved.conf(5) which states “Use the construct "~." to use the system DNS server defined with DNS= preferably for all domains”? Is there a bug? -- TIA Roman. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] how to depend the service which is triggerred by uevent
Hi, All,
I have two services: service_A and service_B. The service_A which
depends on the tap0 uevent will configure the virtual net,
while the service_B which depends on the virtual net should run After the
service_A, but the "After=Service_A" seems to have no effect.
udev rule:
ACTION=="add", SUBSYSTEM=="net", DEVPATH=="/devices/virtual/net/tap0",
TAG+="systemd", ENV{SYSTEMD_WANTS}+="service_A.service"
service_A.service:
[Unit]
Description=setting up bridge
[Service]
Type=oneshot
ExecStart=-/usr/bin/net_config.sh
RemainAfterExit=yes
service_B.service:
[Unit]
DefaultDependencies=no
After=service_A.service
After=local-fs.target
[Service]
Type=simple
ExecStart=/usr/bin/prog_B
Restart=always
OOMScoreAdjust=-941
[Install]
WantedBy=sysinit.target
Could anyone give me some suggestion?
Thanks!
Best Regards,
Li Cheng
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd doesn't see ttyPS0 devices from udev
On Mi, 23.09.20 18:25, Michael Olbrich (m.olbr...@pengutronix.de) wrote: > On Wed, Sep 23, 2020 at 04:58:57PM +0800, ZhouPeng wrote: > > I find that boot with the 'rescue' option, then exit 'rescue' mode, then > > I can login to the ttyPS0, as below > > You're using a custom kernel, right? Please check the README in the systemd > source tree. Specifically the kernel config options. > > >From what I remember, what you describe happens when CONFIG_FHANDLE is > disabled in the kernel. Just to mention that, newer versions of systemd nowadays have various alternatives in place they can use if name_to_handle_at() (i.e. CONFIG_FHANDLE) is not available: /proc/self/fdinfo/xxx exposes what we need too these days, as does statx(). But of course if you use a really old kernel+systemd version you won't take benefit of this. systemd 237 and kernel 4.18 with fedora 28 is ancient, of course. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
