Lesen hilft! Dort steht doch, dass du das Log generieren kannst. Einfach draufklicken!!
Danach bekommst du die Log-ID, die du dann hier postest.
1 Like
Der Übersetzer läuft ja nur im Browser, hat also keinen Einfluss auf die Speichernutzung des Servers.
Da es sich nicht um ein Netzwerkproblem handelt, liefert der debug upload möglichweise nicht die passenden Infos, aber trotzdem sollte da mal jemand drüber schauen.
Aber die Idee mit htop war gut: Starte mal htop von einer console ist SSH, mache ein screenshot von der Anzeige und poste es hier (nachdem du ggf. identifizieren Inhalte unkenntlich gemacht hast). Da sollten wir sehen können welcher Prozess viel RAM nutzt.
Äußerem kann ein tmpfs verantwortlich sein. Führe mal den folgenden Befehle aus und poste dessen Ausgabe hier:
df | grep tmpfs
Welches OS nutzt du eigentlich? Raspberry Pi OS? Mit Desktop oder Lite?
Sorry hatte übersehen den Harken zusetzen.
Hier ist der Debug-Token ich hoffe er hilft weiter.
Mfg WilDam48
Hey
Anbei eine 1 Screenshot ausgabe von htop.
2 Screenshot ausgabe von df | grep tmpfs.
Zu der Frage welches OS ich benutze Ich habe die Lite Version installiert da hier nur der Pi-Hole
Darauf läuft und ich Linux Anfänger bin.
Ich hoffe ich konnte euch weiter helfen.
Mfg WilDam48
Du musst nicht nur den Haken setzen, sondern danach auf die große Schaltfläche "Generate debug log" klicken. Am Ende wird dir dann ein Link mit einem Token (Zahlen/Buchstabenkombi) angezeigt, diesen musst du hier posten.
Habe ich so gemacht und euch zu gesendet.
Von meinem/meiner Galaxy gesendet
Dann poste bitte hier den debug Token der dir angezeigt wurde, damit der zugehörige upload auch gefunden werden kann.
Zum htop:
Das schaut doch alles sehr normal aus, passt auch zu den ~20% die ja jetzt in Pi-hole angezeigt werden ("RES" Spalte und grüner Teil des Balkens sind relevant). Du sagtest Raspberry Pi OS Lite, aber ein Desktop ist ja installiert und läuft auch, so wie wenn gerade aktiv jemand eingeloggt ist. Ohne autologin wären das vielleicht 50 MiB weniger, ohne Desktop (man kann ja auch den Login-Manager und damit den X Server Start komplett deaktivierten, oder deinstallieren) über 100 MiB weniger. Aber bisher ist es ja alles andere als knapp.
tmpfs RAM Speicher sind ebenfalls keine unerwarteten.
Sollte das nun weiter ansteigen, kannst du ja bei 50% oder so noch einmal beides checken und ggf posten, dann sollte man denn verantwortlichen Prozess/tmpfs sehen.
Sorry hatte übersehen den Harken zusetzen.
Hier ist der Debug-Token ich hoffe er hilft weiter.
Mfg WilDam48
Die Nummer des Tokens fehlt!
Nummer ? Ich habe keine Nummer
Aber ich sende dir die LOG-Datei als TXT Datei.
Vielleicht reicht das ja.
Oder du musst mir die Nummer sagen wo sie steht.
Mfg WilDam48
Generate-debug-log.txt (42.9 KB)
|
Gert_Chlupaty
May 25
|
- | - |
Die Nummer des Tokens fehlt!
Nummer ? Ich habe keine Nummer
Aber ich sende dir die LOG-Datei als TXT Datei.
Vielleicht reicht das ja.
Oder du musst mir die Nummer sagen wo sie steht.
Mfg WilDam48
Generate-debug-log.txt (42.9 KB)
The idea behind the debug upload is that you don't need to make it readable to everyone but only to authorised people from the Pi-hole team. When you hit the "Generate debug log" button, you should be shown a random string, to post here. Pi-hole team guys can then find and read the full log, but not users like me that might be able to use the info to hack into your system or so 
. But so far I couldn't see some problematic info (public IP address or hostname).
Here is the debug token (from the end of the log): r8cft8cigk
So you may want to remove the files again from here, just to be sure .
PIHOLE_DNS_1=127.0.0.1#5353
Does it mean you have Unbound or another local DNS server running which Pi-hole uses as upstream? Ah lol, the htop screenshot shows Unbound. 16 MiB RAM usage, that is okay.
Aside of two failures which seem like bugs in the debug script itself (resolving IPv6 hostname via upstream DNS and blocking page X header), everything looks pretty fine. As said, now RAM usage is perfectly fine as well, but when it raises over time, check htop and df again whether you can identify the process or tmpfs that uses that unexpected large amount of memory.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.