[SSD Abnutzung maßgeblich reduzieren]

20 minutes ago, mgutt said:

Vielleicht machst du ein Backup von appdata/pihole und löschst dann pihole und installierst es neu. Dann stoppen und Backup wiederherstellen und wieder starten. Oder der Fehler steckt schon in den Appdata Dateien... Aber probier es erstmal so.

 

Das hat leider auch nicht funktioniert - gleicher Fehler. Der DNS-Service startet nicht.

 

Vermutlich habe ich mir an irgendeiner Stelle was zerschossen. Da ich Unraid noch nicht so lange nutze ist es vermutlich leichter, den Server neu aufzusetzen, als jetzt noch weiter nach der Ursache zu suchen. So werde ich es machen

 

Vielen Dank, dass du dir immer soviel Zeit nimmst, den Usern von Unraid und dieses Forums mit Rat und Tat zur Seite zu stehen! 👍

 

Viele Grüße

Marc

[SSD Abnutzung maßgeblich reduzieren]

31 minutes ago, mgutt said:

Diese Aussage verstehe ich nicht. Das Docker Image oder auch wenn du auf Verzeichnis umstellst, hat ja gar nichts mit dem appdata Share zu tun? Wohin hattest du den denn verschoben?

 

Das sieht auf jeden Fall sauber aus (abgesehen von dem fehlenden RAID = denk an Backups):

Entschuldige, da habe ich mich unklar ausgedrückt. 

 

Ich habe alle Shares vom Cache mittels Mover auf das Array verschoben, als ich bei deinem optionalen Schritt, das Dateisystem auf XFS umzustellen, war. Ich habe aber überlesen, dass du von nur einer SSD sprachst - ich habe aber zwei SSD s als Cache im Einsatz. Also bin ich wieder bei BTRFS und habe alle Shares zurück auf den Cache schieben lassen.

 

Die Backups speichere ich auf meiner Synology - und von da gehen die allerwichtigsten Dateien in die Syno-Cloud. Für einen Privathaushalt Sicherheit genug, denke ich

[SSD Abnutzung maßgeblich reduzieren]

47 minutes ago, mgutt said:

Mit der RAM Disk hat das denke ich nichts zu tun, aber durch diese Änderung werden alle Container neu installiert. Hattest du evtl ein Custom Netzwerk, was jetzt fehlt?

 

 

Kann es sein, dass du auch mal was bei den Cache Einstellungen deines appdata Shares geändert hast? Check mal bitte Shares > appdata Ordnersymbol rechts > LOCATION. Steht über nur "cache"?

 

 

Ich denke auch, dass es nichts mit der RAM Disk zu tun hat.

 

Ich bin mir nicht bewusst, dass ich ein Custom Netzwerk hatte. Die Netzwerkeinstellungen von Docker habe ich nie geändert. Und außerhalb der GUI von Unraid habe ich auch keine Änderungen an den Netzwerkeinstellungen vorgenommen. Daher habe ich mir auch keine Gedanken darüber gemacht, dass ich irgendetwas hätte sichern müssen.

 

Leider habe ich die Datei docker.img inzwischen gelöscht - sonst könnte ich zurück und schauen, ob es mit den alten Einstellungen läuft. 🤦‍♂️

 

Bedingt durch den Wechsel vom Image auf das o.g. Verzeichnis habe ich /appdata verschoben, aber natürlich alles wieder zurückgeholt.

 

Ganz herzlichen Dank, dass du mir hilfst. 

[SSD Abnutzung maßgeblich reduzieren]

13 minutes ago, mgutt said:

 

Wenn du nichts geändert hast, warum schreibst du dann in diesem Thread?

 

Sorry, ich habe deine Frage hinsichtlich der Änderung wohl falsch verstanden.

 

In den Container-Einstellungen zu pi-hole hatte ich zunächst nichts geändert. Allerdings funktionierte pi-hole nicht mehr, nachdem ich die RAM-Disk nach deiner Anleitung erstellt und in den Docker-Einstellungen vom Image auf den Pfad /mnt/cache/system/docker/docker/ gewechselt habe. Daher bin ich davon ausgegangen, dass ich mit meinem Problem hier richtig bin. Ich kann aber gerne einen eigenen Thread dafür eröffnen.

[SSD Abnutzung maßgeblich reduzieren]

Das sieht dann so aus:

 

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
3: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/gre 0.0.0.0 brd 0.0.0.0
4: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1464 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
6: ip_vti0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
7: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
23: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default 
    link/ether 02:42:0a:01:01:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0

 

[SSD Abnutzung maßgeblich reduzieren]

Kurzer Nachtrag.

 

In den Einstellungen zu Docker ist br0 aufgeführt. Auch das Subnetz passt.

 

[SSD Abnutzung maßgeblich reduzieren]

Ich habe nichts geändert. Ok, inzwischen schon, da ich verschiedene Einstellungen versucht habe. 

 

Pi-hole startet ja auch und der Aufruf der WebUI ist möglich, aber in der GUI steht dann, DNS service not running.

 

Habe nochmal ins Protokoll geschaut, hier habe ich nun gefunden:

 

Starting pihole-FTL (no-daemon) as pihole
'unknown': unknown terminal type.
Device "br0" does not exist.
Device "br0" does not exist.
Device "eth0@if11" does not exist.
Device "eth0@if11" does not exist.

 

Kann es sein, dass Docker br0 nicht mehr findet, obwohl mir dieses Netzwerk in Unraid angezeigt wird?

 

[SSD Abnutzung maßgeblich reduzieren]

Hallo zusammen!

 

Erstmal vielen Dank für die tolle Anleitung. Ich habe zwar nicht alles verstanden, konnte meinen Server aber soweit anpassen, dass die Schreibvorgänge nun definitiv reduziert wurden.

 

Allerdings habe ich nun ein Problem mit dem "pihole-template"-Container. Der DNS-Dienst innerhalb des Containers wird nicht gestartet. Im Protokoll steht:

 

Spoiler

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-resolver-resolv: applying...
[fix-attrs.d] 01-resolver-resolv: exited 1.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 20-start.sh: executing...
::: Starting docker specific checks & setup for docker pihole/pihole

[i] Installing configs from /etc/.pihole...
[i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
Setting DNS servers based on PIHOLE_DNS_ variable
::: Pre existing WEBPASSWORD found
DNSMasq binding to custom interface: br0
Added ENV to php:
"PIHOLE_DOCKER_TAG" => "2022.01",
"PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
"ServerIP" => "10.1.1.9",
"CORS_HOSTS" => "",
"VIRTUAL_HOST" => "10.1.1.9",
Using IPv4
::: Preexisting ad list /etc/pihole/adlists.list detected ((exiting setup_blocklists early))
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
::: Testing pihole-FTL DNS: FTL started!
::: Testing lighttpd config: Syntax OK
::: All config checks passed, cleared for startup ...
::: Enabling Query Logging
[i] Enabling logging...
::: Docker start setup complete
Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
Pi-hole version is v5.7 (Latest: v5.7)
AdminLTE version is v5.9 (Latest: v5.9)
FTL version is v5.12.1 (Latest: v5.12.1)
Container tag is: 2022.01
[cont-init.d] 20-start.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
Starting lighttpd
Starting pihole-FTL (no-daemon) as pihole
Starting crond
[services.d] done.
Stopping pihole-FTL
Starting pihole-FTL (no-daemon) as pihole
Stopping pihole-FTL
Starting pihole-FTL (no-daemon) as pihole

 

Hätte ich im Container noch irgendetwas anpassen müssen?

 

Viele Grüße

Marc

 

[logger: send message failed: Bad file descriptor]

13 hours ago, mgutt said:

Nein, ich hatte das nur als Fehlerursache erwartet. Also dass er nicht auf den Stick schreiben kann. Also du kannst es jetzt aktivieren, so dass die Fehler auch nach einem Neustart erhalten bleiben.

 

Dein RAM ist aber in Ordnung? Also ECC ist aktiv und in den Logs sind keine Fehler?

Syslog habe ich jetzt aktiviert.

 

Habe MemTest86x gestern noch 2 x durchlaufen lassen. Glücklicherweise ohne Fehler.

 

ECC ist und war aktiviert.

[logger: send message failed: Bad file descriptor]

1 hour ago, mgutt said:

Hast du den syslog mirror aktiviert?

Danke für deine Nachfrage.

Nein, habe ich nicht. Hätte ich müssen?

[logger: send message failed: Bad file descriptor]

Hallo zusammen, 

 

seit ca. zwei Monaten bin ich ein (fast) glücklicher Unraid-User.

 

Neben dem Problem, dass der Server regelmäßig nach 3 Tagen nicht mehr erreichbar ist und sämtliche Aktivitäten einstellt, erhalte ich am Ende des Boot-Vorganges folgende Meldung:

 

logger: send message failed: Bad file descriptor

 

Hat jemand einen Tipp für mich, weshalb die Meldung erscheint, bzw. wo ich nachschauen könnte, um das Problem näher zu lokalisieren? In den Log-Files bin ich nicht wirklich fündig geworden.

 

Danke und viele Grüße, 

Marc

 

---

Unraid 6.9.2

Asus ROG Strix B550 Gaming-E

Ryzen 5600x

2 x 16GB (1x 16384MB) Kingston Server Premier ECC DDR4-3200 DIMM CL22-22-22 Single

2 x 1TB Crucial MX500 2.5"  (Cache-Pool)

3 x 4TB WD Blue (Array)