April 8, 20215 yr Moin Moin, nach dem Upgrade auf 6.9.1 friert Unraid hin und wieder ein. Nach einem Reboot sind sämtliche Docker Daten unter /mnt/user/appdata auf "auslieferzustand" zurückgesetzt. Mega ärgerlich. Unter 6.8.0 lief das monatelang total stabil was ich lokalisieren konnte war, rootfs steigt von 36% Auslastung auf 100%. out of memory und ich muss den Server neustarten. was mich wundert ist, das Share AppData ist in der Spalte Cache auf Prefer:Cache eingestellt. Es ist jedoch keine zusätzliche SSD als Cache verbaut. Jemand ein Tipp? Systeminfo: M/B: Dell Inc. 07T4MC Version A10 - s/n: /C0KGYH2/CNFCW0089H00NU/ BIOS: Dell Inc. Version 1.0.14. Dated: 05/10/2018 CPU: Intel® Xeon® CPU E3-1225 v5 @ 3.30GHz HVM: Enabled IOMMU: Enabled Cache: 128 KiB, 128 KiB, 1 MB, 8 MB Memory: 8 GiB DDR4 Single-bit ECC (max. installable capacity 64 GiB) Network: bond0: fault-tolerance (active-backup), mtu 1500 eth0: 1000 Mbps, full duplex, mtu 1500 Kernel: Linux 5.10.21-Unraid x86_64 OpenSSL: 1.1.1j Df root@Tower:~# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3938676 1394840 2543836 36% / devtmpfs 3938684 0 3938684 0% /dev tmpfs 4011836 0 4011836 0% /dev/shm cgroup_root 8192 0 8192 0% /sys/fs/cgroup tmpfs 131072 208 130864 1% /var/log /dev/sda1 3907100 532372 3374728 14% /boot overlay 3938676 1394840 2543836 36% /lib/modules overlay 3938676 1394840 2543836 36% /lib/firmware tmpfs 1024 0 1024 0% /mnt/disks tmpfs 1024 0 1024 0% /mnt/remotes /dev/md1 976285620 664839288 311446332 69% /mnt/disk1 /dev/md2 3905110812 680067152 3225043660 18% /mnt/disk2 shfs 4881396432 1344906440 3536489992 28% /mnt/user0 shfs 4881396432 1344906440 3536489992 28% /mnt/user /dev/loop2 20971520 12967292 6982020 66% /var/lib/docker
April 8, 20215 yr Author kann es sein das Docker mir alle Änderungen in der /mnt/user/appdata den RAM reinschreibt?
April 8, 20215 yr 5 minutes ago, dimon said: was mich wundert ist, das Share AppData ist in der Spalte Cache auf Prefer:Cache eingestellt. Es ist jedoch keine zusätzliche SSD als Cache verbaut. Normalerweise ist das egal. Dann wird diese Einstellung ignoriert und er schreibt auf die Disk(s). 2 minutes ago, dimon said: kann es sein das Docker mir alle Änderungen in der /mnt/user/appdata den RAM reinschreibt? Vielleicht ein Schreibfehler bei den Pfaden eines Dockers? Zb mnt statt /mnt oder ein Leerzeichen davor?!
April 8, 20215 yr Author kaum ein bisschen mit unraid gearbeit ist rootfs wieder auf 80% herangewachsen. ich habe lediglich die Datenbank wieder hergestellt. Ich habe das Gefühl, das Unraid mir den RAM vollschreibt. hier die Diagnose-Datei: tower-diagnostics-20210408-2130.zip Edited April 8, 20215 yr by dimon
April 8, 20215 yr Lass dir mal ausgeben wie groß die Hauptverzeichnisse sind: du -sh --exclude=/{proc,sys,dev,mnt,var/lib/docker} /* Sollte zB /tmp groß sein, dann lass dir mal davon die Größen ausgeben: du -sh /tmp/* Oder so kann man sich die 100 aktuellsten Dateien aus dem /tmp Verzeichnis anzeigen lassen: find /tmp -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n100 Vielleicht kommen wir so hinter das Problem. Check auch bitte mal ob hier zufällig das Verzeichnis "cache/" existiert: ls -la /mnt Falls ja, auch davon die Größe ermitteln: du -sh /mnt/cache
April 9, 20215 yr Author root@Tower:~# du -sh --exclude=/{proc,sys,dev,mnt,var/lib/docker} /* 11M /bin 520M /boot 12M /etc 0 /home 0 /hugetlbfs 0 /init 96M /lib 24M /lib64 0 /opt 8.0K /root 484K /run 21M /sbin 20M /tmp 709M /usr 6.7M /var root@Tower:~# du -sh /tmp/* 0 /tmp/CA_logs 0 /tmp/ca.backup2 11M /tmp/community.applications 4.0K /tmp/emhttp 8.5M /tmp/fix.common.problems 4.0K /tmp/huh 4.0K /tmp/huh1 12K /tmp/notifications 376K /tmp/plugins 4.0K /tmp/test 20K /tmp/unassigned.devices 4.0K /tmp/user.scripts root@Tower:~# find /tmp -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n100 2021-04-09 08:22:14.002823104 +0200 /tmp/plugins/fix.common.problems.txt 2021-04-09 08:22:13.947822706 +0200 /tmp/plugins/fix.common.problems.plg 2021-04-09 04:40:06.418592823 +0200 /tmp/notifications/unread/Fix_Common_Problems___Tower_1617936006.notify 2021-04-09 04:40:06.418592823 +0200 /tmp/notifications/archive/Fix_Common_Problems___Tower_1617936006.notify 2021-04-09 04:40:06.406592729 +0200 /tmp/fix.common.problems/errors.json 2021-04-09 04:40:01.882557508 +0200 /tmp/fix.common.problems/moderation.json 2021-04-09 04:40:01.781556721 +0200 /tmp/fix.common.problems/templates.json 2021-04-08 22:04:39.957446116 +0200 /tmp/huh1 2021-04-08 22:04:39.957446116 +0200 /tmp/huh 2021-04-08 22:03:43.850031510 +0200 /tmp/plugins/ca.cfg.editor.txt 2021-04-08 22:03:43.797031118 +0200 /tmp/plugins/ca.cfg.editor.plg 2021-04-08 22:03:41.057010863 +0200 /tmp/plugins/NerdPack.txt 2021-04-08 22:03:40.930009924 +0200 /tmp/plugins/NerdPack.plg 2021-04-08 22:03:40.799008956 +0200 /tmp/plugins/ca.backup2.txt 2021-04-08 22:03:40.673008027 +0200 /tmp/plugins/ca.backup2.plg 2021-04-08 22:03:40.296005237 +0200 /tmp/plugins/ca.cleanup.appdata.txt 2021-04-08 22:03:40.170004303 +0200 /tmp/plugins/ca.cleanup.appdata.plg 2021-04-08 22:03:40.049003411 +0200 /tmp/plugins/community.applications.txt 2021-04-08 22:03:39.920002458 +0200 /tmp/plugins/community.applications.plg 2021-04-08 22:03:39.534999612 +0200 /tmp/plugins/speedtest.txt 2021-04-08 22:03:39.406998667 +0200 /tmp/plugins/speedtest.plg 2021-04-08 22:03:39.122996566 +0200 /tmp/plugins/unassigned.devices.txt 2021-04-08 22:03:38.990995590 +0200 /tmp/plugins/unassigned.devices.plg 2021-04-08 22:03:38.798994171 +0200 /tmp/plugins/user.scripts.txt 2021-04-08 22:03:38.672993240 +0200 /tmp/plugins/user.scripts.plg 2021-04-08 20:20:48.324813581 +0200 /tmp/test 2021-04-08 20:16:59.128178711 +0200 /tmp/community.applications/tempFiles/templates-community-apps/linuxserversRepository/linuxserver-mariadb-latest.xml 2021-04-08 20:16:57.420166478 +0200 /tmp/community.applications/tempFiles/catSearchResults.json 2021-04-08 20:16:57.420166478 +0200 /tmp/community.applications/tempFiles/allSearchResults.json 2021-04-08 20:16:52.192129028 +0200 /tmp/community.applications/tempFiles/displayed.json 2021-04-08 20:16:52.044127968 +0200 /tmp/community.applications/tempFiles/pluginDupes.json 2021-04-08 20:16:52.043127961 +0200 /tmp/community.applications/tempFiles/templates.json 2021-04-08 20:16:51.853126599 +0200 /tmp/community.applications/tempFiles/lastUpdated.json 2021-04-08 20:16:51.725125682 +0200 /tmp/community.applications/tempFiles/sortOrder.json 2021-04-08 20:05:04.617021535 +0200 /tmp/emhttp/smb.service 2021-04-08 19:46:01.447523161 +0200 /tmp/community.applications/tempFiles/repositoryList.json 2021-04-08 19:46:01.447523161 +0200 /tmp/community.applications/tempFiles/categoryList.json 2021-04-08 19:46:01.419522972 +0200 /tmp/community.applications/tempFiles/invalidxml.txt 2021-04-08 19:46:01.404522870 +0200 /tmp/community.applications/tempFiles/lastUpdated-old.json 2021-04-08 19:46:01.404522870 +0200 /tmp/community.applications/tempFiles/currentServer.txt 2021-04-08 18:48:04.907188280 +0200 /tmp/notifications/archive/Fix_Common_Problems___Tower_1617900484.notify 2021-04-08 18:38:30.502011598 +0200 /tmp/user.scripts/booted 2021-04-08 18:38:30.469010411 +0200 /tmp/unassigned.devices/config/unassigned.devices.cfg 2021-04-08 18:38:30.469010411 +0200 /tmp/unassigned.devices/config/samba_mount.cfg 2021-04-08 18:38:30.469010411 +0200 /tmp/unassigned.devices/config/iso_mount.cfg root@Tower:~# ls -la /mnt total 0 drwxr-xr-x 9 root root 180 Apr 8 18:38 ./ drwxr-xr-x 20 root root 440 Apr 8 21:30 ../ drwxr-xr-x 4 root root 80 Apr 9 04:40 cache/ drwxrwxrwx 6 nobody users 63 Apr 9 04:40 disk1/ drwxrwxrwx 11 nobody users 208 Apr 9 04:40 disk2/ drwxrwxrwt 2 nobody users 40 Apr 8 18:38 disks/ drwxrwxrwt 2 nobody users 40 Apr 8 18:38 remotes/ drwxrwxrwx 1 nobody users 63 Apr 9 04:40 user/ drwxrwxrwx 1 nobody users 63 Apr 9 04:40 user0/ --> Interessanterweise wurde user0 erst mit dem Upgrade auf 6.9.0 angelegt. root@Tower:~# du -sh /mnt/cache 2.3G /mnt/cache rootfs wächst wieder an. root@Tower:~# df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 3938676 3151344 787332 81% / devtmpfs 3938684 0 3938684 0% /dev tmpfs 4011836 0 4011836 0% /dev/shm cgroup_root 8192 0 8192 0% /sys/fs/cgroup tmpfs 131072 320 130752 1% /var/log /dev/sda1 3907100 532452 3374648 14% /boot overlay 3938676 3151344 787332 81% /lib/modules overlay 3938676 3151344 787332 81% /lib/firmware tmpfs 1024 0 1024 0% /mnt/disks tmpfs 1024 0 1024 0% /mnt/remotes /dev/md1 976285620 664839288 311446332 69% /mnt/disk1 /dev/md2 3905110812 680309728 3224801084 18% /mnt/disk2 shfs 4881396432 1345149016 3536247416 28% /mnt/user0 shfs 4881396432 1345149016 3536247416 28% /mnt/user /dev/loop2 20971520 12932972 7017044 65% /var/lib/docker
April 9, 20215 yr 42 minutes ago, dimon said: root@Tower:~# du -sh /mnt/cache 2.3G /mnt/cache Du sagtest doch, dass du keinen Cache hast? Ich würde sagen, dass einer deiner Docker Container hier reinschreibt. Und da keine SSD existiert, landen diese Dateien im RAM. Check mal das Verzeichnis: ls -la /mnt/cache/appdata
April 9, 20215 yr Author Genau. Ich habe keine SSD bzw. Cache. Habe da auch nichts verstellt. root@Tower:~# ls -la /mnt/cache/appdata total 0 drwxrwxrwx 8 nobody users 160 Apr 8 20:52 ./ drwxr-xr-x 4 root root 80 Apr 9 04:40 ../ drw-rw-rw- 7 root root 220 Apr 8 19:43 MQTT/ drwxrwxr-x 4 nobody users 120 Apr 8 20:07 binhex-krusader/ drwxr-xr-x 4 nobody users 100 Apr 8 20:52 mariadb/ drwxr-xr-x 8 nobody users 180 Apr 8 21:18 nextcloud/ drwxrwxrwx 7 root root 140 Apr 8 18:41 onlyofficeds/ drwxr-xr-x 4 root root 80 Apr 8 18:38 pihole/ root@Tower:~# Cache-Pool kann auch nicht verstellt werden
April 9, 20215 yr 6 minutes ago, mgutt said: @ich777 warum kann er nicht den Cache deaktivieren? Weil er unten (Select cache pool) keinen gewählt hat oder er schlichtweg keinen hat.
April 9, 20215 yr @dimon Ich vermute es ist folgendes passiert: Irgendein Container hatte /mnt/cache/appdata im Template stehen. Dadurch wurde der Ordner erstellt und nun schreiben alle Container ihre Daten dort rein. Außerdem scheint Unraid einen Bug zu haben. Unraid lässt es zu, dass die Container ihre Dateien dort ablegen, aber erlaubt dir nicht den Cache zu deaktivieren, was dieses Problem verhindern würde. Brauchst du die Dateien oder ist neu installieren in Ordnung?
April 9, 20215 yr 15 minutes ago, mgutt said: Ich vermute es ist folgendes passiert: Irgendein Container hatte /mnt/cache/appdata im Template stehen. Dann tauscht aber die CA App den Pfad automatisch aus auf zB: /mnt/disk1/appdata (eben der erste Pfad wo das Verzeichnis appdata gefunden wird).
April 9, 20215 yr 13 minutes ago, ich777 said: Dann tauscht aber die CA App den Pfad automatisch aus auf zB: /mnt/disk1/appdata Passiert das auch, wenn er mal einen Cache hatte und das Template bei ihm noch lokal vorhanden ist? Irgendwie muss das ja passiert sein. Er wird ja denke ich kein "mkdir" gemacht haben?!
April 9, 20215 yr 5 minutes ago, mgutt said: Passiert das auch, wenn er mal einen Cache hatte und das Template bei ihm noch lokal vorhanden ist? Dann nicht, nur bei der installation aus der CA App soweit ich weiß.
April 9, 20215 yr Author Moin Moin, ne ich hatte nie ein Cache gehabt. Die Probleme sind eigentlich erst nach dem Upgrade von 6.8.x auf 6.9.0 bzw. 6.9.1 gekommen. Wie kann man das nun lösen? Macht es Sinn nun eine SSD als Cache einzubauen?
April 9, 20215 yr 1 hour ago, dimon said: Moin Moin, ne ich hatte nie ein Cache gehabt. Das ist wirklich komisch. 1 hour ago, dimon said: Wie kann man das nun lösen? Vom Prinzip simpel. Du beendest den Docker Dienst in den Einstellungen, wodurch alle Docker gestoppt werden. Dann löschst du einfach den Ordner: rm -r /mnt/user/cache Willst du dagegen die Daten der Container erhalten, kannst du den Inhalt auch auf disk1 verschieben: rsync -av --stats --hard-links --remove-source-files /mnt/user/cache/ /mnt/disk1 rmdir /mnt/user/cache Um das Problem in Zukunft zu vermeiden kannst du außerdem über die Apps den Config Editor installieren und dann bearbeitest du die Datei /boot/config/shares/appdata.cfg und suchst nach dieser Zeile: shareUseCache="prefer" Das "prefer" ersetzt du dann gegen "no" und startest den Server neu. Bei Bedarf machst du das mit allen Shares Config-Dateien so. Danach solltest du in den Share Einstellungen "no" sehen und nicht mehr "prefer". EDIT: Ich habe dazu einen Bug Report eröffnet.
April 9, 20215 yr Du musst mit Schrägstrich anfangen. Also /mnt/cache bzw wenn du im /mnt Verzeichnis bist kannst du auch nur "rm -r cache" eingeben.
April 13, 20215 yr Author ok mein Fehler, bin deiner Anleitung nach gegangen. /mnt/user/cache gab es nicht. war /mnt/cache nach dem löschen habe ich nun auch wieder genug RAM Die Config in Appdata wurde nun ebenfalls angepasst. Frage, wie kann ich die user0 Verknüpfung löschen?
April 13, 20215 yr 40 minutes ago, dimon said: Frage, wie kann ich die user0 Verknüpfung löschen? Daran würde ich nicht rumfummeln. Das gehört zu Unraid. Eventuell verschwindet es, wenn man ohne /mnt/cache neu startet, aber ansonsten würde ich das da lassen.
April 14, 20215 yr Author nein ist nicht verschwunden, jedoch erhalte ich nun durch das plugin folgende Fehlermeldung. der Übeltäter für /mnt/cache war wahrscheinlich PiHole
April 14, 20215 yr 15 minutes ago, dimon said: jedoch erhalte ich nun durch das plugin folgende Fehlermeldung Das ist logisch, wenn PiHole wieder das /mnt/cache Verzeichnis erstellt hat. Du solltest PiHole mal richtig löschen. Also Container weg und dann über Apps > Previous Apps auch das Template der App löschen. Ansonsten lädt der das App Template nicht aus dem App Store, sondern von deinem USB Stick. Deswegen ist der Pfad da auch immer noch /mnt/cache.
Archived
This topic is now archived and is closed to further replies.