Hallo Seit ein paar Tagen (Montag?) bekomme ich diese Meldung in die Logs geschrieben, wenn Fetchmail von t-online Post holen soll: fetchmail: konnte kanonischen DNS-Namen von securepop.t-online.de (securesmpt.t-online.de) nicht finden: Der Name oder der Dienst ist nicht bekannt fetchmail: Abfragestatus=11 (DNS) Wieder muss ich sagen, dass die Einstellungen von andere Stelle übernommen, bzw. dort verwendet werden. Und das dort erfolgreich. FRR
On Thu, 13 May 2021 15:21:11 +0200
Frank Rüdiger Richter
Seit ein paar Tagen (Montag?) D.h., vorher hat es funktioniert, und Du hast seit dem nichts geändert?
fetchmail: Abfragestatus=11 (DNS) man: Fatal DNS error. Fetchmail encountered an error while performing a DNS lookup at startup and could not proceed. D.h., fetchmail kann securepop.t-online.de nicht auflösen.
Wieder muss ich sagen, dass die Einstellungen von andere Stelle übernommen, bzw. dort verwendet werden. Und das dort erfolgreich. Das hat erstmal noch nicht viel zu sagen. Andere Stelle, anderes Environment?
Das kann an Deinem Netz liegen (kannst Du z.B. Web-Sites erreichen [Browser neu starten und mal probieren]?) oder der externe Resolver ist gerade mal nicht verfügbar (passiert hin und wieder mal, vor allem, wenn man nicht die Resolver des ISP nutzt). Wenn die Namensauflösung nicht funktioniert, ist es immer eine gute Idee, da mal mit ping, dig bzw. nslookup nachzuschauen. Viele Grüße Matthias
Hallo Am 13.05.21 um 16:55 schrieb Matthias:
D.h., vorher hat es funktioniert, und Du hast seit dem nichts geändert?
Montag Nachmittag hat es noch funktioniert. Nicht gut, aber die Abholung hat wenigstens funktioniert. Nicht gut bedeutet, es war von Anfang an eigentlich unbrauchbar langsam. Änderungen wurde von mir trotzdem nicht vorgenommen.
fetchmail: Abfragestatus=11 (DNS) man: Fatal DNS error. Fetchmail encountered an error while performing a DNS lookup at startup and could not proceed. D.h., fetchmail kann securepop.t-online.de nicht auflösen.
Wieder muss ich sagen, dass die Einstellungen von andere Stelle übernommen, bzw. dort verwendet werden. Und das dort erfolgreich. Das hat erstmal noch nicht viel zu sagen. Andere Stelle, anderes Environment?
Andere Stelle ist ein Ubuntu. Die mir auch für Opensuse als Muster dienende Konfiguration (Fetchmail, Procmail, Spamassassin, Postfix) ist damit seit mehr als 15 Jahre erfolgreich im Einsatz.
Das kann an Deinem Netz liegen (kannst Du z.B. Web-Sites erreichen [Browser neu starten und mal probieren]?) oder der externe Resolver ist gerade mal nicht verfügbar (passiert hin und wieder mal, vor allem, wenn man nicht die Resolver des ISP nutzt).
Wenn die Namensauflösung nicht funktioniert, ist es immer eine gute Idee, da mal mit ping, dig bzw. nslookup nachzuschauen.
Es scheint überhaupt nichts mehr zu gehen, außer ein ping -c5 2.2.2.2 Das liefert die erwarteten Angaben zurück. Eine Verbindung via Browser zu einer beliebigen Webseite lässt sich nicht mehr ausführen. FRR
Am 2021-05-14 um 10:19 schrieb Frank Rüdiger Richter:
Andere Stelle ist ein Ubuntu. Die mir auch für Opensuse als Muster
dienende Konfiguration (Fetchmail, Procmail, Spamassassin, Postfix) ist
damit seit mehr als 15 Jahre erfolgreich im Einsatz.
Das ist ja auch nicht ursächlich für das Problem...
Das kann an Deinem Netz liegen (kannst Du z.B. Web-Sites erreichen [Browser neu starten und mal probieren]?) oder der externe Resolver ist gerade mal nicht verfügbar (passiert hin und wieder mal, vor allem, wenn man nicht die Resolver des ISP nutzt).
Wenn die Namensauflösung nicht funktioniert, ist es immer eine gute Idee, da mal mit ping, dig bzw. nslookup nachzuschauen.
Es scheint überhaupt nichts mehr zu gehen, außer ein ping -c5 2.2.2.2 Das liefert die erwarteten Angaben zurück. Eine Verbindung via Browser zu einer beliebigen Webseite lässt sich nicht mehr ausführen.
Dann würde ich mal einen Blick auf die /etc/resolv.sonf werfen. Da sollten funktionierende Nameserver drinstehen. Bei mir es es die Adresse des Routers, eine Fritzbox. Die Date ist eigentlich bei allen Hosts im Netz gleich. Bei SUSE kannst Du Nameserver auch in der Datei /etc/sysconfig/network/config vorgeben (Parameter NETCONFIG_DNS_STATIC_SERVERS) und mit dem Befehl "netconfig update -f" erzeugst Du die Datei /etc/resolv.conf neu. HDH, Werner --
Hallo Ich relativiere meine Auskunft von heute Morgen. Eine Änderung ist am Montag Nachmittag vorgenommen worden. Ich haben den nicht funktionierenden Modemmanager de-installiert. Am 14.05.21 um 13:03 schrieb Werner Flamme:
Dann würde ich mal einen Blick auf die /etc/resolv.sonf werfen. Da sollten funktionierende Nameserver drinstehen. Bei mir es es die Adresse des Routers, eine Fritzbox.
Die ist im Fall des Rechners mit Opensuse komplett leer. Und bleibt es auch wenn ich den Befehl netconf update -f (an anderer Stelle gelesen) ausführe. Folgendes führt aber wenigstens wieder zu einem temporären Funktion des Netzwerkes: Trage ich im Networkmanager (KDE) den DNS Server 208.67.222.222, oder einen vergleichbaren ein, dann funktioniert zumindest ein Verbindungsaufbau per Browser wieder. Fetchmail meldet damit allerdings einen Timeout wegen Zeitüberschreitung. Lösung kann das aber für mich eh nicht sein. Damit umgehe ich die Funktionen meines Pi-Hole. FRR
Ich nutze den Networkmanager überhaupt nicht.
Nutze grundsätzlich wicked.
Da kann man dann auch dns und alles andere einstellen.
Meiner Meinung nach für Server eh besser.
Vielleicht hilft der dir bei deinem Problem auch.
Gruß
Eric
Am 14. Mai 2021 17:31:55 MESZ schrieb "Frank Rüdiger Richter"
Hallo
Ich relativiere meine Auskunft von heute Morgen. Eine Änderung ist am Montag Nachmittag vorgenommen worden. Ich haben den nicht funktionierenden Modemmanager de-installiert.
Am 14.05.21 um 13:03 schrieb Werner Flamme:
Dann würde ich mal einen Blick auf die /etc/resolv.sonf werfen. Da sollten funktionierende Nameserver drinstehen. Bei mir es es die Adresse des Routers, eine Fritzbox.
Die ist im Fall des Rechners mit Opensuse komplett leer. Und bleibt es auch wenn ich den Befehl netconf update -f (an anderer Stelle gelesen) ausführe.
Folgendes führt aber wenigstens wieder zu einem temporären Funktion des Netzwerkes: Trage ich im Networkmanager (KDE) den DNS Server 208.67.222.222, oder einen vergleichbaren ein, dann funktioniert zumindest ein Verbindungsaufbau per Browser wieder. Fetchmail meldet damit allerdings einen Timeout wegen Zeitüberschreitung. Lösung kann das aber für mich eh nicht sein. Damit umgehe ich die Funktionen meines Pi-Hole.
FRR
Am 14.05.21 um 19:01 schrieb Eric Schirra:
Ich nutze den Networkmanager überhaupt nicht. Nutze grundsätzlich wicked. Da kann man dann auch dns und alles andere einstellen. Meiner Meinung nach für Server eh besser.
Hallo Der fragliche Rechner ist kein Server, sondern ein ganz normaler, schon etwas älterer Laptop. Eine am Wochenende vorgenommene erneute Komplettinstallation hat als Ergebnis dass das Booten (1x 1 TB Samsung SSD/1x 2 TB Seagate HDD) im günstigsten Fall 2 1/2 Minuten braucht, im ungünstigen Fall 4 Minuten. Offenbar ist das aktivieren der Netzwerkschnittstellen (LAN, bzw. WLAN) die Bremse. Ich weiß nicht, ab ich nach mehr als 5 Wochen basteln noch Lust zur Ursachenforschung oder Suche nach Möglichkeiten der Beseitigung aufbringe. FRR
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Montag, den 17.05.2021, 15:22 +0200 schrieb Frank Rüdiger Richter:
Eine am Wochenende vorgenommene erneute Komplettinstallation hat als Ergebnis dass das Booten (1x 1 TB Samsung SSD/1x 2 TB Seagate HDD) im günstigsten Fall 2 1/2 Minuten braucht, im ungünstigen Fall 4 Minuten. Offenbar ist das aktivieren der Netzwerkschnittstellen (LAN, bzw. WLAN) die Bremse. Ich weiß nicht, ab ich nach mehr als 5 Wochen basteln noch Lust zur Ursachenforschung oder Suche nach Möglichkeiten der Beseitigung aufbringe.
Welcher Dienst lange zum starten benötigt bzw. das System beim Start ausbremst kannst Du mit dem Befehl 'systemd-analyze blame' herausfinden. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIyBAEBCgAdFiEEQR38BJqrIG9dBQ3+IUsgEK6S/5AFAmCoU+0ACgkQIUsgEK6S /5C8Ew/41MhX50lujjcCjTMK9GSq7p6ZsDtdyqqP8NEq4efahHu/EQLgT4UAfjTn FY68lHtEAfyykcQLrUn7hbnvcvKFQa21aYEPXs2gIDHp3NaQEBvuIorn2vx8rlGc qSfs9th8WEQdsIuUY/D83p6qFGkoX3E1hJArzJoQ4E2dWk4JR0xz88rg+4wuq0h3 IhGniwwiXQGABgywsaeJj3aEeGUtnVgGpxDwlV27mI1qoahuUGjnpFL6w6w+gv9p kCIjxRRnfi5zjeijtEngJBe+JHv12UZvH/lJjm6aa3xfRKT98Q7pwcSW1Dwz3ZXJ mvxmZ4wGp9S8cwHZut1VJ8VXmWSFWmJaG4skSBOj1UdMTGxkbWpoTdJfwtNXMNTt OzEAPzdZZAjk2CKgN0jgdgxa+C5A6WGMsjTV0J4cNnNAGR01NZK/60KdUaQhNqNt nnaa2Uih/TFFi5fbHFHXmMzj/U6qHXv5XFmlmV3uartutHWiGJQgWp9Pq9UD8U2S 8ME80h5VNxJTuJUkDyNdK8RHi2cywYvO795eGxf+wtOXh1HFF1K3Sl2RRBdUU8VC jOUhE/cBtNUf0Zo9J7HucAiwk+OqNNyoZ4YKxUa/8+Gd5u5w/BVDvE0RQsIKkQOO rmw6VumGIVg9qPJdhjfrB8+dRkRL8226l08spe24dnxV1tHj/Q== =r4bz -----END PGP SIGNATURE-----
Hallo Am 22.05.21 um 02:44 schrieb Richard Kraut:
Welcher Dienst lange zum starten benötigt bzw. das System beim Start ausbremst kannst Du mit dem Befehl 'systemd-analyze blame' herausfinden.
Ich habe mich darauf beschränkt den Ablauf der Bootvorgangs in Echtzeit zu verfolgen. Nach durchschnittlich 13,4 Sek. (auf dem Ubuntusystem bin ich da im Normalfall bereits angemeldet) stockt der Ablauf mit einer Meldung a la A Start Job is running for..., beim eth0 etwa 1 1/2 Minuten. Bei aktiven (Hardwareschalter) wlan0 bis zu 4 Minuten. Beides zusammen schweige wir besser. Das ist inakzeptabel. FRR
Am Samstag, 22. Mai 2021, 17:11:49 CEST schrieb Frank Rüdiger Richter:
Hallo
Am 22.05.21 um 02:44 schrieb Richard Kraut:
Welcher Dienst lange zum starten benötigt bzw. das System beim Start ausbremst kannst Du mit dem Befehl 'systemd-analyze blame' herausfinden.
Ich habe mich darauf beschränkt den Ablauf der Bootvorgangs in Echtzeit zu verfolgen. Nach durchschnittlich 13,4 Sek. (auf dem Ubuntusystem bin ich da im Normalfall bereits angemeldet) stockt der Ablauf mit einer Meldung a la A Start Job is running for..., beim eth0 etwa 1 1/2 Minuten. Bei aktiven (Hardwareschalter) wlan0 bis zu 4 Minuten. Beides zusammen schweige wir besser. Das ist inakzeptabel.
FRR
verrätst du uns auch wie dein netzwerk konfiguriert ist? Statisch, oder dhcp? cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am Samstag, den 22.05.2021, 17:11 +0200 schrieb Frank Rüdiger Richter:
Ich habe mich darauf beschränkt den Ablauf der Bootvorgangs in Echtzeit zu verfolgen.
Hoffentlich dann auch mit abgeschaltetem Splash und Plymouth. Sonst wird schon diese Ausgabe kastriert.
Nach durchschnittlich 13,4 Sek. (auf dem Ubuntusystem bin ich da im Normalfall bereits angemeldet) stockt der Ablauf mit einer Meldung a la A Start Job is running for..., beim eth0 etwa 1 1/2 Minuten. Bei aktiven (Hardwareschalter) wlan0 bis zu 4 Minuten.
Gibt es bei Dir eine Netzwerkfreigabe, welche Du beim Startvorgang gleich einbinden möchtest? Wird bei Dir der NetworkManager, Wicked oder Wicd verwendet? Du kannst natürlich auch den Timeout für den entsprechenden Dienst anpassen, so dass der Bootvorgang schneller wird und Systemd nicht immer bis zu 90 Sek. (ist der Default-Wert) wartet, wenn ein Dienst oder ein Mount nicht so recht will. Andererseits kann das natürlich auch andere Probleme hervorrufen. Für das ändern des Timeouts für einen bestimmten Dienst musst aber dessen Namen wissen (bspw. wicked.service) und logischerweise sollte es sich auch um den Dienst handeln, welcher den Startvorgang lange aufhält. - -- MfG Richi -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQR38BJqrIG9dBQ3+IUsgEK6S/5AFAmCpLgMACgkQIUsgEK6S /5Dryg//Z89XuuSLIogbbtHWe4mQQI5LqqxyEKMl3WBEHcSVFQhXQiRTVMvpTQxc zICLE+2kRH1JOtSnL+MI0CoiGWTIqSQ+xpx3ulN762XEyn3s1jfjR0I7yE0zyHjP pB09w236l6frsB7P52Jaw9ueNjlttfs3yliSDIMpOty285wWnMO4N4wDkNGKVXth H2Y9awqh8F53jW1JdhBQEFYuFMiqBOwowgK44TCC2tYDE76BTU52OLNLtjej/vyQ 4f+I4J1h+BvQAWzBSKXlnM03L40wGAPlCjsqQTWPjKJxU9tcf7j72ZBCjjoklDpA RO4zYeMi6N0xoRX8Onjon+Avjla/oBU4ywmAs6HjL5sbS9yRKpODurP51o8wAAUo JAjf+sPecjVYnYJesAyRtBEHYY1wpnpKcYryb9bCDBwgufz0+Cc1pYIITdK+j/Rx s7BX6h1mnIPgTeY/M1bH7bZ47jAehoYX7oZoTykOJHGQaM4VfdYMTWGZtV4qZJGZ xPNHKSkFu58qITvpajLb4eERp+MtzBf9ZesZMyN/LU21bcfUDj/one6BcuvuuHg5 r92Mt2ado1pdRlTXpFF+ohGn46Nk4E9l6gC3pHtFGXTuKpQ5RsKqdcMD4uSt30ZC 1gzdUULjSnOsnk5rSN3fN0tZJbZWyJMs8FVG+aDmok5MVJPa58U= =LQ+4 -----END PGP SIGNATURE-----
Hallo Es war ein ganz normale Installation von der DVD. Nur die notwendigsten Eingriff bei der Partitionierung, wegen der 2 Festplatten. Alles andere wurde übernommen wie von openSUSE Mein Netzwerk ist an sich recht übersichtlich aufgebaut. Der Router soll jedem Rechner eine fest vorgegeben IP zuweisen. Klappte in den letzten Versuchen auch nicht, da der Laptop (aus welchen Gründen auch) immer wieder eine neue MAC generiert hat. Ein schönes Pfingstfest wünscht allen Frank Rüdiger Richter Am 22.05.21 um 18:14 schrieb Richard Kraut:
Am Samstag, den 22.05.2021, 17:11 +0200 schrieb Frank Rüdiger Richter:
Ich habe mich darauf beschränkt den Ablauf der Bootvorgangs in Echtzeit zu verfolgen.
Hoffentlich dann auch mit abgeschaltetem Splash und Plymouth. Sonst wird schon diese Ausgabe kastriert.
Nach durchschnittlich 13,4 Sek. (auf dem Ubuntusystem bin ich da im Normalfall bereits angemeldet) stockt der Ablauf mit einer Meldung a la A Start Job is running for..., beim eth0 etwa 1 1/2 Minuten. Bei aktiven (Hardwareschalter) wlan0 bis zu 4 Minuten.
Gibt es bei Dir eine Netzwerkfreigabe, welche Du beim Startvorgang gleich einbinden möchtest?
Wird bei Dir der NetworkManager, Wicked oder Wicd verwendet?
Du kannst natürlich auch den Timeout für den entsprechenden Dienst anpassen, so dass der Bootvorgang schneller wird und Systemd nicht immer bis zu 90 Sek. (ist der Default-Wert) wartet, wenn ein Dienst oder ein Mount nicht so recht will. Andererseits kann das natürlich auch andere Probleme hervorrufen. Für das ändern des Timeouts für einen bestimmten Dienst musst aber dessen Namen wissen (bspw. wicked.service) und logischerweise sollte es sich auch um den Dienst handeln, welcher den Startvorgang lange aufhält.
Am Sonntag, dem 23.05.2021 um 11:29 +0200 schrieb Frank Rüdiger Richter:
Klappte in den letzten Versuchen auch nicht, da der Laptop (aus welchen Gründen auch) immer wieder eine neue MAC generiert hat.
Diese Verhalten hat mich vor längerer Zeit auch ziemliche Nerven gekostet. Mit dem Kommandozeilenprogramm MAC Changer (im Paket macchanger) kann man das zwar ändern. Ist aber IMO eher die Bekämpfung der Wirkung, nicht der Ursache. -- Sebastian Hoffmeister _________________________________________________________________ ________________________________________________________ Ihr Recht auf Privatsph�re. Sch�tzen Sie Ihre Daten und wechseln jetzt zu eclipso Mail & Cloud - https://www.eclipso.de
Am 23.05.21 um 15:11 schrieb Sebastian Hoffmeister:
Am Sonntag, dem 23.05.2021 um 11:29 +0200 schrieb Frank Rüdiger Richter:
Klappte in den letzten Versuchen auch nicht, da der Laptop (aus welchen Gründen auch) immer wieder eine neue MAC generiert hat.
Diese Verhalten hat mich vor längerer Zeit auch ziemliche Nerven gekostet. Mit dem Kommandozeilenprogramm MAC Changer (im Paket macchanger) kann man das zwar ändern. Ist aber IMO eher die Bekämpfung der Wirkung, nicht der Ursache.
Falls der NetworkManager im Spiel ist: in /etc/NetworkManager/NetworkManager.conf kommt folgender Abschnitt rein: [device] wifi.scan-rand-mac-address=no Hendrik
Hallo Zu spät. Selbst wenn ich das zustande kommen und denn Sinn dieses Verhaltens nachvollziehen könnte - von meinem über mehrere Wochen verfolgten Vorhaben, mein derzeitiges Linux durch openSUSE zu ersetzen, habe ich nun Abstand genommen. Danke für alles Tipps und Versuche mir bei der Klärung von Problemen zu helfen. FRR Am 23.05.21 um 16:52 schrieb Hendrik Woltersdorf:
Am 23.05.21 um 15:11 schrieb Sebastian Hoffmeister:
Am Sonntag, dem 23.05.2021 um 11:29 +0200 schrieb Frank Rüdiger Richter:
Klappte in den letzten Versuchen auch nicht, da der Laptop (aus welchen Gründen auch) immer wieder eine neue MAC generiert hat.
Diese Verhalten hat mich vor längerer Zeit auch ziemliche Nerven gekostet. Mit dem Kommandozeilenprogramm MAC Changer (im Paket macchanger) kann man das zwar ändern. Ist aber IMO eher die Bekämpfung der Wirkung, nicht der Ursache.
Falls der NetworkManager im Spiel ist:
in /etc/NetworkManager/NetworkManager.conf kommt folgender Abschnitt rein: [device] wifi.scan-rand-mac-address=no
Hendrik
Am 22. Mai 2021 17:11:49 MESZ schrieb "Frank Rüdiger Richter"
Hallo
Am 22.05.21 um 02:44 schrieb Richard Kraut:
Welcher Dienst lange zum starten benötigt bzw. das System beim Start ausbremst kannst Du mit dem Befehl 'systemd-analyze blame' herausfinden.
Ich habe mich darauf beschränkt den Ablauf der Bootvorgangs in Echtzeit zu verfolgen. Nach durchschnittlich 13,4 Sek. (auf dem Ubuntusystem bin ich da im Normalfall bereits angemeldet) stockt der Ablauf mit einer Meldung a la A Start Job is running for..., beim eth0 etwa 1 1/2 Minuten. Bei aktiven (Hardwareschalter) wlan0 bis zu 4 Minuten. Beides zusammen schweige wir besser. Das ist inakzeptabel.
FRR
Das ist mir bei verschiedenen Systemen auch schon aufgefallen. Der langsamste Dienst ist immer die Aktivierung des Netzwerks wie du es beschreibst. Gruß Eric
Am 2021-05-14 um 17:31 schrieb Frank Rüdiger Richter:
Hallo
Ich relativiere meine Auskunft von heute Morgen. Eine Änderung ist am Montag Nachmittag vorgenommen worden. Ich haben den nicht funktionierenden Modemmanager de-installiert.
Am 14.05.21 um 13:03 schrieb Werner Flamme:
Dann würde ich mal einen Blick auf die /etc/resolv.sonf werfen. Da sollten funktionierende Nameserver drinstehen. Bei mir es es die Adresse des Routers, eine Fritzbox.
Die ist im Fall des Rechners mit Opensuse komplett leer. Und bleibt es auch wenn ich den Befehl netconf update -f (an anderer Stelle gelesen) ausführe.
Folgendes führt aber wenigstens wieder zu einem temporären Funktion des Netzwerkes: Trage ich im Networkmanager (KDE) den DNS Server 208.67.222.222, oder einen vergleichbaren ein, dann funktioniert zumindest ein Verbindungsaufbau per Browser wieder. Fetchmail meldet damit allerdings
einen Timeout wegen Zeitüberschreitung.
Ner Netzwerkmanager befummelt auf meinen Laptops, wo ich ihn benutze, auch nur die Datei /etc/resolv.conf.
Lösung kann das aber für mich eh nicht sein. Damit umgehe ich die Funktionen meines Pi-Hole.
Trage "nameserver <ip-deines-pihole>" in die Datei /etc/resolv.conf ein.
FRR
Werner --
participants (8)
-
Eric Schirra -
Frank Rüdiger Richter -
Hendrik Woltersdorf -
Mathias Homann -
Matthias -
Richard Kraut -
Sebastian Hoffmeister -
Werner Flamme