Pasadena Posted February 18, 2021 Share Posted February 18, 2021 Hallo, Ich habe eine Basic Lizenz und meinen Unraid nun soweit eingerichtet, wie ich es haben möchte. Seit kurzem stelle ich fest, das das Dashboard, also die Weboberfläche, locker 5-7 Minuten braucht, um angesprochen zu werden. Die Docker-Apps und Shares und VMs sind alle schon lange am laufen. Ich kann mich erinnern, das die Weboberfläche direkt nach dem Start erreichbar war. Wieso dauert es jetzt so lange? Hat das jemand auch beobachtet oder hat eine Idee, was das sein könnte oder wo ich schauen kann? Hardware ist i5-10210U mit 8GB Ram und SSD Festplatte. Es stört nicht so gewaltig, die Zeit nehme ich mir halt, aber wenn sich das abstellen ließe...... Quote Link to comment
mgutt Posted February 18, 2021 Share Posted February 18, 2021 6 minutes ago, Pasadena said: Seit kurzem stelle ich fest, das das Dashboard, also die Weboberfläche, locker 5-7 Minuten braucht, um angesprochen zu werden. Vielleicht irgendwas in den Systemlogs zu sehen? (Tools) Aber die GUI ist nach den 7 Minuten schnell oder? Nicht, dass der RAM bei dir einfach überfüllt ist. Quote Link to comment
Pasadena Posted February 19, 2021 Author Share Posted February 19, 2021 (edited) Hallo, Nee, ich glaube nicht, das es am RAM liegt, nach dem Start (also nach 500-600 Sekunden) ist die Seite sofort da und läuft auch sehr flüssig. Im LOG habe ich folgendes gefunden, was vielleicht ein Hinweis sein könnte: Feb 19 18:54:40 UnRaid avahi-daemon[3232]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on vethxxxxxx.*. .... hier sind die 5 Minuten Wartezeit, dann geht es weiter. Ist es das? Feb 19 18:59:42 UnRaid ntpd[1855]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Feb 19 18:59:41 UnRaid ntpd[1855]: frequency error -597 PPM exceeds tolerance 500 PPM -- hier auch nochmal ein bisschen... Feb 19 19:00:08 UnRaid unassigned.devices: Cannot 'Auto Mount' Remote Shares. Network not available! Feb 19 19:00:08 UnRaid emhttpd: shcmd (80): /etc/rc.d/rc.php-fpm start Feb 19 19:00:08 UnRaid root: Starting php-fpm done Feb 19 19:00:08 UnRaid emhttpd: shcmd (81): /etc/rc.d/rc.nginx start Feb 19 19:00:08 UnRaid root: Starting Nginx server daemon... Feb 19 19:00:08 UnRaid root: error: /webGui/include/ProcessStatus.php: wrong csrf_token Keine Ahnung, ob der falsche Token noch ne Rolle spielt, sgat mir nix. jedenfalls geht es danach. Ich weiß, das es vorher nicht war. Ich benutze auch gar kein IPV6, weiß also auch nicht, was da passiert. Edited February 19, 2021 by Pasadena Quote Link to comment
mgutt Posted February 19, 2021 Share Posted February 19, 2021 13 minutes ago, Pasadena said: Keine Ahnung, ob der falsche Token noch ne Rolle spielt, sgat mir nix Das kommt manchmal, wenn man mehrere Unraid Fenster parallel offen hat oder nach einem Reboot noch offen sind. Kann man ignorieren. 14 minutes ago, Pasadena said: Feb 19 18:54:40 UnRaid avahi-daemon[3232]: Registering new address record for fe80::xxxx:xxxx:xxxx:xxxx on vethxxxxxx.*. Deaktiviere mal Bonjour. Scheint damit zusammen zu hängen: https://forums.unraid.net/topic/43942-what-is-avahi-daemon/ Quote Link to comment
Pasadena Posted February 20, 2021 Author Share Posted February 20, 2021 Unter Settings ist AFP schon deaktiviert. Das hat aber nix gebracht. Gibt es für Bonjour noch eine andere Einstellung? Unter Netzwerkeinstellungen gibt es ganz unten noch die Routing Tabelle. Da steht ein einziger IPv6 Eintrag drin mit Route ::1 am Gateway IO. Soll ich den mal rausnehmen? Quote Link to comment
Pasadena Posted February 20, 2021 Author Share Posted February 20, 2021 Oder kann man den Nginx protokolliert starten lassen, um mal zu schauen, was er hat. Ich vermute, das Problem liegt da irgendwo. Quote Link to comment
mgutt Posted February 20, 2021 Share Posted February 20, 2021 Hast du über UD einen SMB Share auf Auto Mount stehen? Weil bei mir kommt direkt nach der Registrierung der IPv6 (ich habe auch IPv6 deaktiviert, keine Ahnung warum Docker sich trotzdem eine holt) ein Auto Mount: Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered blocking state Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered disabled state Feb 8 02:36:13 Thoth kernel: device vethf60763d entered promiscuous mode Feb 8 02:36:13 Thoth kernel: IPv6: ADDRCONF(NETDEV_UP): vethf60763d: link is not ready Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered blocking state Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered forwarding state Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered disabled state Feb 8 02:36:13 Thoth kernel: eth0: renamed from vetha78f512 Feb 8 02:36:13 Thoth kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethf60763d: link becomes ready Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered blocking state Feb 8 02:36:13 Thoth kernel: docker0: port 1(vethf60763d) entered forwarding state Feb 8 02:36:13 Thoth kernel: IPv6: ADDRCONF(NETDEV_CHANGE): docker0: link becomes ready Feb 8 02:36:13 Thoth rc.docker: Plex-Media-Server: started succesfully! Feb 8 02:36:14 Thoth avahi-daemon[5031]: Joining mDNS multicast group on interface docker0.IPv6 with address fe80::42:2bff:xxxx:xxxx. Feb 8 02:36:14 Thoth avahi-daemon[5031]: New relevant interface docker0.IPv6 for mDNS. Feb 8 02:36:14 Thoth avahi-daemon[5031]: Registering new address record for fe80::42:2bff:xxxx:xxxx on docker0.*. Feb 8 02:36:14 Thoth avahi-daemon[5031]: Joining mDNS multicast group on interface vethf60763d.IPv6 with address fe80::40f3:58ff:fe66:c31e. Feb 8 02:36:14 Thoth avahi-daemon[5031]: New relevant interface vethf60763d.IPv6 for mDNS. Feb 8 02:36:14 Thoth avahi-daemon[5031]: Registering new address record for fe80::40f3:58ff:xxxx:xxxx on vethf60763d.*. Feb 8 02:36:15 Thoth unassigned.devices: Mounting 'Auto Mount' Remote Shares... Feb 8 02:36:15 Thoth sudo: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/local/emhttp/plugins/unbalance/unbalance -port 6237 Feb 8 02:36:15 Thoth unassigned.devices: Mount SMB share '//DESKTOP-xxxx/Users' using SMB default protocol. Feb 8 02:36:15 Thoth unassigned.devices: Mount SMB command: /sbin/mount -t cifs -o rw,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=99,gid=100,credentials='/tmp/unassigned.devices/credentials_Users' '//DESKTOP-xxxx/Users' '/mnt/remotes/DESKTOP-xxxx_Users' Feb 8 02:36:15 Thoth kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. Feb 8 02:36:15 Thoth unassigned.devices: Successfully mounted '//DESKTOP-xxxx/Users' on '/mnt/remotes/DESKTOP-xxxx_Users'. Sollte dieser Server offline sein, kann es tatsächlich 5 Minuten dauern bis der Verbindungsversuch abbricht. Quote Link to comment
Pasadena Posted February 20, 2021 Author Share Posted February 20, 2021 Hmmm, ich habe keine Remote Shares, ist alles intern verbaut. Ich hatte mal kurz eine Plattre über USB dran, um zu schauen, ob sie erkannt wird, hab sie aber nicht gemountet, soviel ich weiß und auch gleich wieder abgezogen. Aber du hast mich auf eine Idee gebracht. Ich habe mal den Netzwerkehr mitgeplottet, während UnRaid bootet. An der entscheidenen Stelle lässt UnRaid (oder nginx) tatsächlich tonnenweise Portabfragen los, hauptsächlich 137 und 138 also Netbios und MS, und dann noch weitere. Die werden von meiner Firewall blockiert. Schalte ich die Firewall testweise mal aus und boote dann, ist das Dashboard tatsächlich relativ schnell da. Was ist denn da los? Das muss doch nicht sein, oder? Oder habe ich mit der externen Platte was ausgelöst, was jetzt in irgendeiner Config steht? Jedenfalls bootet er ohne Firewall fehlerfrei. Mit Firewall kommen die obigen Fehler und das Dashboard braucht 5 Minuten. Alles andere (Docker, VMs) sind sofort da. Quote Link to comment
mgutt Posted February 20, 2021 Share Posted February 20, 2021 Findest du was in Richtung Netzwerk und "fail" in deinen Logs? Oder "timeout"? Wenn es SMB ist, worauf Port 137/138 hindeutet, könnte man das doch denke ich auch ohne Neustart provozieren. Führe mal im Webterminal das aus: samba restart Dauert das mehr als ein paar Sekunden? Ansonsten könntest du noch mit deaktiviertem SMB starten. Und dann könnte man überlegen SMB2 als kleinste Version vorauszusetzen. Dann dürfte Port 137/138 nicht mehr benötigt werden: # Set minimum SMB protocol server min protocol = SMB2_10 client min protocol = SMB2_10 client max protocol = SMB3 Auch danach samba restart ausführen. Wenn du dagegen SMB1 benötigst, musst du logischerweise auch die Ports dafür öffnen. Quote Link to comment
Pasadena Posted February 20, 2021 Author Share Posted February 20, 2021 Ein Samba restart dauert nur 1-2 Sekunden. Das ist es also auch nicht. Was solls, so wichtig ist es ja nicht. Aber komisch schon. Werde mal ne Weile weiterforschen, vielleicht sehe ich mit Wireshark mehr. Fakt ist jedenfalls, das irgendein Prozess auf etwas wartet, was über LAN geht. Ich melde mich, wenn ich schlauer geworden bin. Danke erst Mal. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.