# [?solved?] KDE Plasma 5 - überall 10 Sekunden warten

## schmidicom

Seit kurzem hat meine KDE Plasma 5 Umgebung offenbar die ultra nervige Angewohnheit angefangen bei jedem FileOpen-Dialog oder Dolphin start die jeweilige Anwendung einfach mal 10 Sekunden lang nicht mehr reagieren zu lassen.

Hier mal einen strace von einem kwrite wo der FileOpen-Dialog geöffnet wurde:

```
...

14:21:04 write(5, "\1\0\0\0\0\0\0\0", 8) = 8

14:21:04 ppoll([{fd=28, events=POLLIN}], 1, {tv_sec=30, tv_nsec=0}, NULL, 8) = 1 ([{fd=28, revents=POLLHUP}], left {tv_sec=29, tv_nsec=997617973})

14:21:04 write(5, "\1\0\0\0\0\0\0\0", 8) = 8

14:21:04 read(28, "", 12)               = 0

14:21:04 write(5, "\1\0\0\0\0\0\0\0", 8) = 8

14:21:04 close(28)                      = 0

14:21:04 ppoll([{fd=-1}, {fd=24, events=POLLIN}, {fd=26, events=POLLIN}, {fd=30, events=POLLIN}], 4, {tv_sec=29, tv_nsec=998000000}, NULL, 8) = 2 ([{fd=24, revents=POLLHUP}, {fd=26, revents=POLLHUP}], left {tv_sec=18, tv_nsec=934247812})

14:21:15 ioctl(24, FIONREAD, [0])       = 0

14:21:15 read(24, "", 1)                = 0

14:21:15 write(5, "\1\0\0\0\0\0\0\0", 8) = 8

14:21:15 close(24)                      = 0

14:21:15 ioctl(26, FIONREAD, [0])       = 0

14:21:15 read(26, "", 1)                = 0

14:21:15 write(5, "\1\0\0\0\0\0\0\0", 8) = 8

...
```

Da ist klar zu erkennen das 10 Sekunden lang einfach gar nichts mehr passiert und während diesen 10 Sekunden ist das Programm dann nicht mehr bedienbar, also eingefroren. Das selbe passiert auch wenn der Dolphin geöffnet wird, kurz nach dem das Fenster da ist reagiert es 10 Sekunden lang einfach nicht mehr.

Hat hier irgendjemand eine Idee wie dem Ursprung von diesem Scheiß Bug auf die schliche komme ohne gleich eine riesen Downgrade/Reinstall/Upgrade-Orgie zu veranstalten?

Die Ausgabe von Strace selbst ist leider alles andere als hilfreich, sie bestätigt halt nur das es passiert.

EDIT ?solved?:

Ein veralteter Eintrag in der "/etc/samba/smb.conf" brachte den Dolphin und andere Komponenten des KDE dazu unsinnige DNS-Anfragen auszulösen wie kein DNS-Server erfolgreich auflösen konnte. Und weil der systemd-resolved bis zu 5 Sekunden lang versuchte das aufzulösen blockierte der Dolphin.Last edited by schmidicom on Mon Aug 19, 2019 9:46 am; edited 4 times in total

----------

## mike155

Mir kommen spontan folgende Ideen in den Sinn:

Hast Du in der letzten Zeit etwas an Deinem System geändert? Neue Versionen installiert? Oder irgendeine Hardware-Änderung? Vielleicht einen neuen Kernel installiert?

ppoll() wartet ja darauf, dass sich bei den File-Deskriptoren etwas ändert: Schau Dir im strace Log an, was sich hinter den File-Deskriptoren verbirgt.

Du hast strace offenbar mit Option "-t", aber nicht mit Option  "-f" aufgerufen? Bitte rufe es noch einmal auf und füge Option"-f" hinzu. Wenn Du magst, poste das Ergebnis über wgetpaste

Du könntest das Programm mit Debug Symbolen übersetzen und aus gdb starten. Während der 10 Sekunde Pause brichst Du das Programm ab und generierst einen Backtrace für alle Threads:

```
thread apply all bt
```

Beim ersten Mal sind werden vermutlich recht viele Namen mit "??" angezeigt - dann musst Du weitere Pakete mit Debug Symbolen übersetzen. 

Jedenfalls weißt Du dann, was die Prozesse / Threads machen und kannst im Quellcode nachsehen.

----------

## schmidicom

1.

Eine Menge, ich bin von VirtualBox auf libvirt umgestiegen habe ein World-Update gefahren und so weiter...

Das alles wieder zurück zu verfolgen, geschweige denn Rückgängig zu machen, kann ich gleich vergessen.

2. und 3. Keine Ahnung was ppoll genau macht oder was File-Deskriptoren sind, aber ich werde mir das strace nochmal ansehen...

4. Wenn alles andere fehlschlägt probiere ich das vielleicht aus aber ich bin ehrlich kein Fan davon das Debug-Flag zu aktivieren...

----------

## mike155

 *schmidicom wrote:*   

> 1. Eine Menge, ich bin von VirtualBox auf libvirt umgestiegen habe ein World-Update gefahren und so weiter...
> 
> Das alles wieder zurück zu verfolgen, geschweige denn Rückgängig zu machen, kann ich gleich vergessen.
> 
> 

 

Ich sehe das ganz positiv: wenn Du viel geändert hast, gibt es sicherlich einen Grund, warum es nicht mehr geht. Und vermutlich müssen die Ergebnisse von weiteren Tests Dich nur in die richtige Richtung schubsen - dann fällt Dir wieder ein, was Du geändert hast und Du kannst es rückgängig machen. 

 *schmidicom wrote:*   

> 4. Wenn alles andere fehlschlägt probiere ich das vielleicht aus aber ich bin ehrlich kein Fan davon das Debug-Flag zu aktivieren...

 

Es ist leider nicht hilfreich, das Debug USE-Flag zu setzen. Hier gibt's die Anleitung: https://wiki.gentoo.org/wiki/Debugging. Die wesentlichen Schritte sind:

Create the files '/etc/portage/env/debugsyms' and '/etc/portage/env/installsources' as shown on the Wiki page 

Add the packages you want to debug to '/etc/portage/package.env' (as shown on the Wiki page)

Re-emerge the packages you added to '/etc/portage/package.env'

Run your program in gdb

----------

## schmidicom

Hier mal das strace, diesmal von dolphin.

https://drive.google.com/file/d/1_7W26T6Pn1ZskCKVO21V-F3G4Fl7OWub/view?usp=sharing

EDIT:

Das muss irgendein Netzwerkmist sein.

Lösche ich die "/etc/resolv.conf" so das kein DNS mehr zur Verfügung steht verhält sich der Dolphin und alle FileOpen-Dialoge wieder völlig normal. Sobald ich die "/etc/resolv.conf" aber wiederherstelle ist auch das Problem wieder da.

Nur was genau der Dolphin da bis zu 10 Sekunden lang per DNS versucht aufzulöschen, weiß ich nicht...

----------

## mike155

 *schmidicom wrote:*   

> Das muss irgendein Netzwerkmist sein.
> 
> Lösche ich die "/etc/resolv.conf" so das kein DNS mehr zur Verfügung steht verhält sich der Dolphin und alle FileOpen-Dialoge wieder völlig normal. Sobald ich die "/etc/resolv.conf" aber wiederherstelle ist auch das Problem wieder da.
> 
> Nur was genau der Dolphin da bis zu 10 Sekunden lang per DNS versucht aufzulöschen, weiß ich nicht...

 

Spannend! Zu dem gleichen Ergebnis bin ich auch gerade gekommen. Ich habe mir Deinen Strace Log angesehen und bin auf folgende Zeilen gestoßen (Port 53=DNS):

```
24121 15:39:10 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 4

24121 15:39:10 connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0

...

24121 15:39:10 poll([{fd=4, events=POLLIN}], 1, 5000 <unfinished ...>

```

Das sind die Zeilen kurz vor einer 5 Sekunden Pause. Nach der Pause wird poll() ein zweites Mal ausgeführt, was wieder zu fast 5 Sekunden Pause führt - insgesamt also 10 Sekunden Pause.

==> Überprüfe mal alles, was mit DNS zu tun hat.

Was verwendest Du OpenRC? Oder Systemd?

----------

## schmidicom

Ich benutze eine Kombination von NetworkManager und systemd-resolved, wobei letzterer als lokaler DNS-Cache eingerichtet ist.

Offenbar will der Dolphin irgendeine Domain (welche genau werde ich wohl nie erfahren) auflösen und der systemd-resolvd versucht das zwar (vermutlich nicht nur beim vom NetworkManager angegebenen DNS-Server sondern auch bei jedem einzelnen FallBack-DNS-Server) gibt dann aber nach 5 Sekunden erfolglos auf. Fürs erste bleibt mir wohl oder übel nichts anderes übrig als den Symlink "/etc/resolve.conf" von "/run/systemd/resolve/stub-resolv.conf" auf "/run/systemd/resolve/resolv.conf" umzustellen, wodurch der systemd-resolved zu einem reinen Verwalter der DNS-Einstellungen degradiert wird.

Mich würde ja mal brennend interessieren was zum Teufel die KDE-Entwickler geritten hat das sie auf die glorreiche Schnapsidee kommen den Dolphin im Hardcore-Style auf das auflösen irgendeiner ominösen Domain warten zu lassen!

Und das ganze dann gleich noch zweimal hintereinander...   :Evil or Very Mad:   :Evil or Very Mad:   :Evil or Very Mad: 

----------

## mike155

 *Quote:*   

> Ich benutze eine Kombination von NetworkManager und systemd-resolved, wobei letzterer als lokaler DNS-Cache eingerichtet ist.

 

Es spricht nichts gegen Systemd und auch nichts gegen NetworkManager. 

Ich selbst benutze Systemd und systemd-networkd.

Es spricht aber einiges dagegen, Systemd für die DNS Namensauflösung zu nutzen. Paul Vixie hat sich deutlich dagegen ausgesprochen und ich stimme ihm da zu. Nach Möglichkeit sollten alle Programme die alten Wege und Libraries für die DNS Namensauflösung verwenden und Systemd in weitem Abstand umgehen. 

 *Quote:*   

> den Symlink "/etc/resolve.conf" von "/run/systemd/resolve/stub-resolv.conf" auf "/run/systemd/resolve/resolv.conf" umzustellen

 

Ich würde stattdessen empfehlen, den Symlink zu entfernen und wieder die gute alte /etc/resolv.conf Datei von Hand anlegen. Je weniger Systemd mit DNS zu tun hat, desto besser (s.o.). 

Siehe: 'man systemd-resolved', Abschnitt '/ETC/RESOLV.CONF'.

----------

## schmidicom

Das sehe ich ganz anders und die Mozilla-Devs dürften da ähnlich denken.

Der übliche DNS-Client von Linux ist genau so mangelhaft wie der von Windows.

Er kennt kein DNSSEC, DoT oder DoH und es gibt kein Interface für andere Programme wie Beispielweise den NetworkManager um bei einem Wechsel des Netzwerks eine Konfigurationanpassung zu veranlassen. Ein sauber implementierter Cache (nscd sehe ich nicht als das an) ist im übrigen genau so wenig vorhanden wie ein automatischer FallBack auf alternative DNS-Server.

Für mich ist dieser Workaround auf dauer nicht akzeptabel und wenn die KDE-Devs ihren Dolphin nicht bald reparieren werde ich dazu einen Bugreport eröffnen.

----------

## asturm

 *schmidicom wrote:*   

> Für mich ist dieser Workaround auf dauer nicht akzeptabel und die KDE-Devs ihren Dolphin nicht bald reparieren werde ich dazu einen Bugreport eröffnen.

 

...wäre ein Bugreport nicht eher am Anfang des Prozesses?

----------

## schmidicom

 *asturm wrote:*   

> ...wäre ein Bugreport nicht eher am Anfang des Prozesses?

 

Und wo soll der sein wenn nicht bei KDE?

systemd-resolved verhält sich doch genau so wie es das sollte. Es versucht etwas aufzulösen was über den ersten DNS-Server nicht aufgelöst werden kann und geht dann seine Liste an Ersatzserver durch bis es nach 5 Sekunden gezwungen ist aufzugeben. "net-dns/openresolv" oder irgend ein anderer Resolver mit ähnlichen Fähigkeiten würde sich doch kein Stück anders verhalten. Außerdem sollte eine Anwendung nicht vollkommen blockieren nur weil sie auf die Auflösung einer Domain wartet.

EDIT:

Ein Webbrowser beliebt ja auch noch bedienbar wenn er auf die IP-Adresse wartet.

----------

## mike155

 *schmidicom wrote:*   

> Für mich ist dieser Workaround auf dauer nicht akzeptabel und wenn die KDE-Devs ihren Dolphin nicht bald reparieren werde ich dazu einen Bugreport eröffnen.

 

Warum willst Du bei den KDE-Entwicklern einen Bug öffnen, wenn Dein DNS Resolving nicht funktioniert? 

Schau Dir den Strace Log an: es wird ein Request an systemd-resolved gesendet, aber es kommt keine Antwort zurück. Das Problem liegt nicht bei Dolphin, KDE oder Qt, sondern bei  systemd-resolved und Deinem DNS Resolving Setup. DNS Resolving ist die Basis von allem. Es muss einfach funktionieren.

----------

## schmidicom

Wäre das wirklich so müssten auch andere Komponenten ein Problem haben, ist aber nicht der Fall.

----------

## mike155

 *schmidicom wrote:*   

> Wäre das wirklich so müssten auch andere Komponenten ein Problem haben, ist aber nicht der Fall.

 

Bitte keine voreiligen Schlüsse...

Wenn Du dem strace log nicht traust: häng Dich mit tcpdump oder Wireshark rein und schau Dir an, welche Anfrage gesendet wird und ob / was systemd-resolved antwortet. Da ich jetzt auch schon einige Zeit mit dem Fall verbracht habe, interessiert es mich auch, welche DNS Anfrage Dolphin / KDE/ Qt senden und ob / was systemd-resolved darauf antwortet. Dann sehen wir ja, wer schuld ist.

----------

## schmidicom

Werde ich am kommenden Montag mal machen...

----------

## firefly

Um zu testen ob dnssec überhaupt funktioniert gibt es zwei tests um das zu verifizieren:

Hierfür wird das tool dig aus net-dns/bind-tools verwendet.

Die Ausgaben sind von meinem system wo NetworkManager + dnsmasq verwendet wird (https://wiki.gentoo.org/wiki/NetworkManager#NetworkManager_way)

Wobei dnsmasq nur als dns caching proxy dient. Und daher ist in dnsmasq selbst kein dnssec aktiviert (Wenn aktiv bricht es die dns ausflösung, da der dns meines router nur dnssec proxy spielt und dadurch überhaupt keine auflösung mehr stattfindet. Es läuft dann in einen timeout).

(Quelle für die tests: https://techglimpse.com/dns-dnssec-testing-validating-tools/)

Erfolgreiche DNSSEC Validierung:

```
$ dig dnssectest.sidn.nl +dnssec +multi

; <<>> DiG 9.14.4 <<>> dnssectest.sidn.nl +dnssec +multi

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14732

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 1232

; COOKIE: 7120fea039f0a408436e799d5d579aebe4cb16d2d6842883 (good)

;; QUESTION SECTION:

;dnssectest.sidn.nl.   IN A

;; ANSWER SECTION:

dnssectest.sidn.nl.   3600 IN   A 213.136.9.12

dnssectest.sidn.nl.   3600 IN   RRSIG A 8 3 3600 (

            20190915071059 20190816071059 42033 sidn.nl.

            HslinXKfBufJ4vlnIznnsdaSV45qcEyiWFe9F8Bh5Nl8

            XepczJtD01+DBNzBlTu0Tz1o29+3ZLBobqWSCVhRzxjG

            gSbkessg5bkiJA5YVuh4hZ6/Bx7OHFAkv/q55tmbybIE

            2DKgGjPwNpNeXcoeBLySa1bPQkS/Hs9TBdkHQvY= )

;; Query time: 83 msec

;; SERVER: ::1#53(::1)

;; WHEN: Sat Aug 17 08:13:25 CEST 2019

;; MSG SIZE  rcvd: 258
```

Fehlerhafte DNSSEC Validierung (in der quelle wird dnssec-or-not.org verwendet um die ausgabe für eine fehlerhafte  dnssec konfiguration zu zeigen, da aber die seite selbst eine dnssec test implementiert habe ich die domain mit der richtigen ausgetauscht, welche von dem website test verwendet wird)

```
$ dig bad.dnssec-or-not.com  +dnssec +multi

; <<>> DiG 9.14.4 <<>> bad.dnssec-or-not.com +dnssec +multi

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46828

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 1232

; COOKIE: 770ef885ac63cbe58d60fc125d579cb0d2029f86140ae542 (good)

;; QUESTION SECTION:

;bad.dnssec-or-not.com.   IN A

;; Query time: 610 msec

;; SERVER: ::1#53(::1)

;; WHEN: Sat Aug 17 08:21:04 CEST 2019

;; MSG SIZE  rcvd: 78
```

Bzw. test via website:

http://dnssec-or-not.org/

EDIT: Das in meinem Setup keine dns auflösung mehr funktionet wenn in dnsmasq dnssec aktiviert wird könnte daran liegen, dass dnsmasq von networkmanager mit dem parameter --proxy-dnssec gestartet wird und dadurch dnsmasq selbst nur ein dnssec proxy ist. Das beist sich wohl mit der aktivierung von dnssec in der dnsmasq konfiguration.

----------

## schmidicom

So die Analyse mit Wireshark ist nun da:

https://drive.google.com/file/d/1gmboYDWBlcgfF5nTZpYzriqEx3Eq-M_J/view?usp=sharing

Hier noch ein paar Infos:

172.16.0.170 - Das ist mein Gentoo Linux

172.16.0.167 - Das ist meine libvirt-VM

172.16.0.2 + 172.16.0.3 - Die beiden DNS-Server

```
br_vlan10: verbunden to br_vlan10

        "br_vlan10"

        bridge, 1A:05:9D:63:58:04, sw, mtu 1500

        ip4-Vorgabe

        inet4 172.16.0.170/24

        route4 172.16.0.0/24

        route4 0.0.0.0/0

        inet6 fe80::eb57:ba43:9450:4746/64

        route6 fe80::/64

        route6 ff00::/8

eno1: verbunden to uplink1

        "Intel Ethernet"

        ethernet (e1000e), 38:2C:4A:70:BC:D0, hw, mtu 1500

        inet6 fe80::3a2c:4aff:fe70:bcd0/64

        route6 fe80::/64

        route6 ff00::/8

vnet0: verbunden to vnet0

        "vnet0"

        tun, FE:54:00:D2:42:A7, sw, mtu 1500

        Master br_vlan10

vlan10: verbunden to vlan10

        "vlan10"

        vlan, 38:2C:4A:70:BC:D0, sw, mtu 1500

        Master br_vlan10

        route6 ff00::/8

lo: nicht verwaltet

        "lo"

        loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536

DNS configuration:

        servers: 172.16.0.2 172.16.0.3

        domains: mgdom.ch

        interface: br_vlan10
```

An der Wireshark-Aufzeichnung kann man erkennen das beim öffnen des Dolphin einige unsinnige DNS-Requests ("A vlan10" und "AAAA vlan10") ausgelöst werden.

Meine Vermutung schein bestätigt, die DNS-Server 172.16.0.2 und 172.16.0.3 geben natürlich sofort auf aber der systemd-resolved versucht mit jeden FallBack-Server doch noch irgend eine bracuhbare Antwort zu liefern was dann eben dementsprechend lange dauert.

Es bleibt jedoch die Frage warum macht der Dolphin (und andere Komponenten des KDE Plasma 5) so etwas und warum blockiert er vollständig bis er eine Antwort erhält?

Neuer Workaround:

Ich habe in der "/etc/hosts" bei "127.0.0.1" und "::1" den Namen "vlan10" eingetragen und damit gibt es keine verzögerungen mehr, auch nicht wenn "/etc/resolv.conf" auf "/run/systemd/resolve/stub-resolv.conf" zeigt.

----------

## firefly

Hat einer der systeme vlan10 als hostname?

Falls ja wie erhält das system seine IP-Adresse?

Falls die adresse manuell zugewiesen ist dann gibt es keinen DNS-Server (Der auch DHCP spielt) der den hostnamen kennt.

Dann ist klar was los ist. Daher ist die Lösung den hostname in der hosts datei einzutragen kein Workaround sondern die Lösung.

----------

## schmidicom

Die IP-Adresskonfiguration wird schon seit Ewigkeiten manuell gemacht und nein "vlan10" ist nicht der Hostname sondern "pc170am", dieser Hostname ist in den beiden DNS-Servern 172.16.0.2 / 172.16.0.3 registriert.

```
schmidicom@pc170am ~> cat /etc/hostname 

pc170am
```

Der Name "vlan10" kommt nur innerhalb der NetworkManager-Konfiguration vor und auch da nicht als Hostname.

```
[connection]

id=uplink1

uuid=2d28eb19-9505-420c-9ae1-5c033f1010e9

type=ethernet

permissions=

[ethernet]

auto-negotiate=true

mac-address=38:2C:4A:70:BC:D0

mac-address-blacklist=

[ipv4]

dns-search=

method=disabled

[ipv6]

addr-gen-mode=stable-privacy

dns-search=

method=ignore
```

```
[connection]

id=vlan10

uuid=4be4df46-79a9-427e-8383-790567d5b4bb

type=vlan

interface-name=vlan10

master=5e861ed5-e465-4c7f-984d-021b2885912c

permissions=

slave-type=bridge

[ethernet]

mac-address-blacklist=

[vlan]

egress-priority-map=

flags=1

id=10

ingress-priority-map=

parent=2d28eb19-9505-420c-9ae1-5c033f1010e9
```

```
[connection]

id=br_vlan10

uuid=5e861ed5-e465-4c7f-984d-021b2885912c

type=bridge

interface-name=br_vlan10

permissions=

[ipv4]

address1=172.16.0.170/24,172.16.0.1

dns=172.16.0.2;172.16.0.3;

dns-search=mgdom.ch;

may-fail=false

method=manual

[ipv6]

addr-gen-mode=stable-privacy

dns-search=

ip6-privacy=0

method=link-local
```

----------

## firefly

Da ein DNS Request nach vlan10 als "hostname" gemacht wird muss irgendwo dieser name als bestandteil einer Netzwerk URI/URL verwendet werden.

Und was sagt der befehl hostname?

Denn es kann sein dass der Hostname durch einen dienst überschrieben wird und dadurch der eintrag in /etc/hostname nicht verwendet wird

----------

## schmidicom

 *firefly wrote:*   

> Da ein DNS Request nach vlan10 als "hostname" gemacht wird muss irgendwo dieser Name als Bestandteil einer Netzwerk URI/URL verwendet werden.

 

Würde mich auch interessieren wo KDE diesen her nimmt...

 *firefly wrote:*   

> Und was sagt der befehl hostname?

 

```
schmidicom@pc170am ~> hostname

pc170am
```

```
schmidicom@pc170am ~> hostnamectl 

   Static hostname: pc170am

         Icon name: computer-desktop

           Chassis: desktop

        Machine ID: bbb8d7caf5404e37b4bf2ee222c0f404

           Boot ID: 49de5b2b60a948bda27b5768eec73ed7

  Operating System: Gentoo/Linux

            Kernel: Linux 5.2.8-gentoo

      Architecture: x86-64
```

----------

## Max Steel

würde wahrscheinlich mal ein "grep -r vlan10 /etc ~" probieren... irgendwo muss das Ding ja herkommen, oder nicht?

----------

## mike155

Ich habe mir gerade den tcp dump angesehen. Soweit ich sehe, werden alle Anfragen sofort beantwortet. Möglicherweise hast Du den Dump noch nicht richtig erstellt. Wir suchen nach einer Anfrage, die NICHT beantwortet wird und die nach 5 Sekunden wiederholt wird.

----------

## schmidicom

 *Max Steel wrote:*   

> würde wahrscheinlich mal ein "grep -r vlan10 /etc ~" probieren... irgendwo muss das Ding ja herkommen, oder nicht?

 

```
/etc/hosts:127.0.0.1    pc170am.mgdom.ch pc170am localhost vlan10

/etc/hosts:::1          pc170am.mgdom.ch pc170am localhost vlan10

/etc/samba/smb.conf:        interfaces = lo vlan10

/etc/NetworkManager/system-connections/vlan10.nmconnection:id=vlan10

/etc/NetworkManager/system-connections/vlan10.nmconnection:interface-name=vlan10

/etc/NetworkManager/system-connections/br_vlan10.nmconnection:id=br_vlan10

/etc/NetworkManager/system-connections/br_vlan10.nmconnection:interface-name=br_vlan10

/etc/libvirt/qemu/PC167AM.xml:      <source bridge='br_vlan10'/>
```

Der Eintrag in "/etc/hosts" habe ich erst heute eingetragen um den Dolphin ruhig zu stellen, aber das in der "/etc/samba/smb.conf" weckt mein misstrauen.

Um libvirt benutzen zu können musste ich einiges umstellen, unter anderem wird die IP-Konfiguration jetzt nicht mehr auf "vlan10" (wie es vorher der Fall war) angewendet sondern eben auf "br_vlan10". Dabei habe ich wohl dem smbd vergessen zu sagen das er jetzt nicht mehr vlan10 als Interface benutzen soll sondern br_vlan10.

Ich stelle das mal um, mal sehen ob sich dadurch was ändert...

----------

## Max Steel

Sieht für mich jetzt im Prinzip auch alles gut aus, das einzige was jetzt noch "fehlen" dürfte wäre der Nachtrag mit "grep -ir 'vlan10' ~"

Denn irgendwie muss dolphin ja auf die Idee kommen...

----------

## schmidicom

Sehr interessant...

Nach der Korrektur in "/etc/samba/smb.conf" löst weder der Dolphin noch irgend ein FileOpen-Dialog eine dieser unsinnige DNS-Abfragen (wie sie im Wireshark-Dump zu finden ist) aus, genau genommen gibt es vom KDE gar eine DNS-Abfragen mehr. Und ohne diese DNS-Abfragen kommt es auch nicht mehr zu einer 10 Sekunden-Blockade.

 *Max Steel wrote:*   

> Sieht für mich jetzt im Prinzip auch alles gut aus, das einzige was jetzt noch "fehlen" dürfte wäre der Nachtrag mit "grep -ir 'vlan10' ~"

 

Ist inzwischen zwar obsolete aber hier noch die geforderte Info:

```
Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/1c5dbd506793b119_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/5b2b325de36ee011_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/694c2e89621e2556_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/31f781032304b41a_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/b7cce7b18b7de2f0_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/728971825d7d96b4_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/bb3da04e200ee164_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/59826c78bbf2df82_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/e5c929e62fc0c62a_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/584a0e1c044901e0_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/1bf53b8b4d16ec94_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/3038370a9a697013_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/4dfbd57e2d092ded_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/c93a000b6b509be4_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/8fe12a810f85b70d_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/b79577ffc8610830_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/c631eab75898c451_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/1fcc5ade5a095601_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/464b1746ffb8e79e_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/5cb6841000c433bf_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/213beafd7d6adc34_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/70f24fdfef603bc8_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/c2cbfa967798345d_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/2c9065b0ed8e803e_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/ca8f10bdd6d233f4_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/c0c6d4c98102a746_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/d6e77c0fd4f01268_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/ef77b66978444251_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/e2d8e58ce6e8c74f_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/6a877e299c01050a_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/769b713605658692_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/19c55f10fcb0e4ab_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/4b5a47d1273dc39e_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/41d29fb2af214653_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/22e21b0c46ee59c9_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/19161ff995f9a877_0

Übereinstimmungen in Binärdatei /home/schmidicom/.cache/chromium/Default/Cache/c1bac8f672f9905e_0

/home/schmidicom/.cache/virt-manager/virt-manager.log:[Mi, 14 Aug 2019 14:35:33 virt-manager 22211] DEBUG (connection:1113) interface=vlan10 status=Aktiv added

/home/schmidicom/.cache/virt-manager/virt-manager.log:[Mi, 14 Aug 2019 16:03:35 virt-manager 2559] DEBUG (connection:1113) interface=br_vlan10 status=Aktiv added

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:       <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:       <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge='br_vlan10'/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:[Mi, 14 Aug 2019 16:13:56 virt-manager 3513] DEBUG (connection:1113) interface=br_vlan10 status=Aktiv added

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:       <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:       <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge="br_vlan10"/>

/home/schmidicom/.cache/virt-manager/virt-manager.log:      <source bridge='br_vlan10'/>

Übereinstimmungen in Binärdatei /home/schmidicom/.config/chromium/Default/Current Tabs

/home/schmidicom/.VirtualBox/Machines/Haiku/Haiku.vbox-prev:          <BridgedInterface name="vlan10"/>

/home/schmidicom/.VirtualBox/Machines/Haiku/Logs/VBox.log.1:00:00:00.481460   Network              <string>  = "HostInterfaceNetworking-vlan10" (cb=31)

/home/schmidicom/.VirtualBox/Machines/Haiku/Logs/VBox.log.1:00:00:00.481461   Trunk                <string>  = "vlan10" (cb=7)

/home/schmidicom/.VirtualBox/Machines/Haiku/Logs/VBox.log.1:00:00:00.590307 IntNet#0: szNetwork={HostInterfaceNetworking-vlan10} enmTrunkType=3 szTrunk={vlan10} fFlags=0x8000 cbRecv=325632 cbSend=196608 fIgnoreConnectFailure=false

/home/schmidicom/.VirtualBox/Machines/Haiku/Logs/VBox.log:00:00:00.945433   Network              <string>  = "HostInterfaceNetworking-vlan10" (cb=31)

/home/schmidicom/.VirtualBox/Machines/Haiku/Logs/VBox.log:00:00:00.945434   Trunk                <string>  = "vlan10" (cb=7)

/home/schmidicom/.VirtualBox/Machines/Haiku/Logs/VBox.log:00:00:01.053133 IntNet#0: szNetwork={HostInterfaceNetworking-vlan10} enmTrunkType=3 szTrunk={vlan10} fFlags=0x8000 cbRecv=325632 cbSend=196608 fIgnoreConnectFailure=false

/home/schmidicom/.VirtualBox/Machines/Haiku/Haiku.vbox:          <BridgedInterface name="vlan10"/>

/home/schmidicom/.gradle/daemon/3.5/daemon-7055.out.log:16:12:48.596 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface vlan10

/home/schmidicom/.gradle/daemon/3.5/daemon-7055.out.log:16:12:48.597 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /fe80:0:0:0:3a2c:4aff:fe70:bcd0%vlan10

/home/schmidicom/.gradle/daemon/3.5/daemon-7055.out.log:16:12:48.598 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote multicast interface vlan10
```

Last edited by schmidicom on Mon Aug 19, 2019 9:36 am; edited 1 time in total

----------

## mike155

Ich finde auch die Ziel-Adresse in dem tcp dump merkwürdig. Laut strace Log wird doch eine Verbindung zu 127.0.0.53 aufgebaut. Diese Pakete sehe ich nicht in dem tcp dump.

Ich würde gerne die Pakete sehen, die Dolphin / KDE / Qt an 127.0.0.53 sendet. Hier würde ich gerne eine Anfrage sehen, die dann von systemd-resolved NICHT beantwortet wird und die nach 5 Sekunden wiederholt wird.

----------

## Max Steel

Möglicherweise stolpere ich hier über belangloses

Hier bei mir in der smb.conf.default steht folgendes

```
# Configure Samba to use multiple interfaces

# If you have multiple network interfaces then you must list them

# here. See the man page for details.

;   interfaces = 192.168.12.2/24 192.168.13.2/24 

```

Instinktiv würde ich auch Device-namen eingeben. Aber evtl macht Dolphin oder was weiß ich komische Dinge wenn man dort interface-namen, die nicht mehr nach Adressen übersetzt werden können, weil die Interfaces sich komplett änderten, statt interface-adressen angibt.

Komische Sache, aber möglicherweise könntest du es dir einfacher machen wenn du direkt deine Adressen hier einträgst.

Edith sagt:

Die Sache mit 127.0.0.53 könnte an der resolve.conf liegen. Ich meine gesehen zu haben dass systemd default-mäßig dass vorschlägt als Adresse für den systemd-resolved.

----------

## schmidicom

 *mike155 wrote:*   

> Ich finde auch die Ziel-Adresse in dem tcp dump merkwürdig. Laut strace Log wird doch eine Verbindung zu 127.0.0.53 aufgebaut. Diese Pakete sehe ich nicht in dem tcp dump.
> 
> Ich würde gerne die Pakete sehen, die Dolphin / KDE / Qt an 127.0.0.53 sendet. Hier würde ich gerne eine Anfrage sehen, die dann von systemd-resolved NICHT beantwortet wird und die nach 5 Sekunden wiederholt wird.

 

Ich musste ja von 127.0.0.53 auf 172.16.0.2 / 172.16.0.3 umstellen um überhaupt wieder einigermaßen arbeiten zu können. Das ändert aber nichts daran das vom KDE unsinnige DNS-Anfragen raus gingen die nicht aufgelöst werden könnten (das Wireshark-Dump beweißt das ja). Der einzige unterschied ist das die beiden Server 172.16.0.2 / 172.16.0.3 sofort aufgeben während systemd-resolved seine ganzen FallBack-Server durchgeht (das sind ja sie 2x5 Sekunden) bevor er sich geschlagen geben muss.

 *Max Steel wrote:*   

> Möglicherweise stolpere ich hier über belangloses
> 
> Hier bei mir in der smb.conf.default steht folgendes
> 
> ```
> ...

 

Ich habe da Interface-Namen drin damit ich bei einem IP-Adresswechsel die smb.conf nicht Anfassen muss (dürfte laut Doku auch erlaubt und kein Problem sein), aber nach diesem Erlebnis werde ich mir das auch nochmal überlegen.

----------

## firefly

Ist der Fehler nun weg (mit systemd-resolve) nachdem du in der smb.conf den fehlerhaften eintrag bei interfaces gefixt hast?

Wenn ja, dann hätte ich folgende Vermutung wieso Dolphin ein DNS request absetzt.

Es kann gut sein, wenn Dolphin die smb.conf parsed und bei den werten für die interfaces variable etwas findet was kein netzwerk-interface (z.b. eth0) oder eine IP-Addresse ist, dass es den wert als einen hostname interpretiert und versucht ihn aufzulösen.

Was im konkreten falle nachtürlich fehlschlägt.

Was an sich kein Problem sein sollte aber durch das unerwartete Verhalten von systemd-resolve kommen die Wartezeiten zustanden.

Wobei hier unter umständen nicht eine KDE komponente selbst das problem ist (smb kio plugin) sondern die samba implementierung an sich. Denn das smb kio plugin verwendet libsmbclient.

Und scheinbar liegt es wirklich an samba selbst.

Laut diesem Bugreport (der nur indirekt was mit dem Problem zu tun hat) https://bugzilla.samba.org/show_bug.cgi?id=11718

sollte man bei interfaces keine hostnames angeben, was aber wohl von samba an sich unterstützt wird.

Das Problem ist, dass wenn libsmbclient für einen interfaces eintrag kein network interface findet, dass es dann versucht den Eintrag als hostname zu interpretieren...

Hier kommen also verschieden Probleme zusammen, welche sich nicht in kde komponenten befinden. Dolphin bzw. kio smb plugin sind nur die auslöser für das eigendliche Problem

----------

## schmidicom

 *firefly wrote:*   

> Ist der Fehler nun weg (mit systemd-resolve) nachdem du in der smb.conf den fehlerhaften eintrag bei interfaces gefixt hast?

 

Ja, jetzt wo die smb.conf korrigiert ist läuft alles wieder normal auch mit systemd-resolved.

----------

## firefly

Nachtrag zu meinen Erkenntnissen.

Laut den sourcen von samba wird für die interfaces config variable auch hostnames unterstützt.

Aus <samba_source>/source3/lib/interface.c (static void interpret_interface(char *token))

 *Quote:*   

>  Interpret a single element from a interfaces= config line.
> 
>  This handles the following different forms:
> 
>  1) wildcard interface name
> ...

 

----------

