mgutt

Ich habe nun den folgenden Weg dem Maintainer vom Template vorgeschlagen: Ist nicht perfekt, aber sollte das Problem lösen.

Unten "add path". Ich würde das Backup wiederherstellen, den Container mit der alten Version taggen und den zweiten Pfad extra hinzufügen. Dann macht der Container das Update und schreibt es nach influxdb2 und gut ist.

Das ist nicht notwendig. Der Container erstellt automatisch eine DB:

Thank you! Works flawlessly: root@Tower:~# pgrep -af http 3337 /usr/local/sbin/emhttpd 4334 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/notify_poller 4336 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/session_check 4338 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/device_list 4340 /bin/bash /usr/local/emhttp/webGui/nchan/disk_load 4342 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/parity_list 4487 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller 4489 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 4491 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 4493 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3 # browser closed, some seconds later... root@Tower:~# pgrep -af http 3337 /usr/local/sbin/emhttpd root@Tower:~#

Sehr gut. Ich hatte tatsächlich den Kommentar nicht mitbekommen. Bei mir landen immer wieder Benachrichtigungen vom Forum im Spamfilter 😒 Funktioniert übrigens auch ohne abmelden. Der überwacht das jetzt absolut sauber. Die Änderung wird außerdem mehr Stabilität bringen: Gibt ja nach wie vor Leute, wo wegen MACVLAN der Server crasht.

The "insert code" form is a huge pain in this forum software. It's extremely slow and it's "fancy" syntax highlighting makes it even slower. Isn't there any bbcode / markup / html code usable to avoid this form? Like: <code>HTML style</code /code Atlassian cloud style [code]bbcode style[/code] Stackoverflow style (4 whitespaces) ``` Github hub style ``` The Atlassian markup is my absolute favorite as it is the fastest way and inserts the code block directly into the textarea while typing the code. And: Why does it force line breaks in code blocks?! This makes code in the mobile view unreadable.

One of the used AWS server IPs is blacklisted: X-policyd-weight: IN_SPAMCOP=3.75 NOT_IN_IX_MANITU=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .unraid. - helo: .a27-18.smtp-out.us-west-2.amazonses. - helo-domain: .amazonses.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -1.75 ... X-KasSpamfilter: match on scbl X-Spam-Flag: YES Because of that I miss some of the forum notifications 😒

Leider nein. Ist zwar immer wieder im Gespräch, aber bisher nicht umgesetzt worden. @hawihoney hat daher Unraid innerhalb von Unraid virtualisiert. Dem kann ich nicht folgen. Die Parity ist einfach außen vor, was den nutzbaren Speicherplatz anbelangt. Sie muss nur eben größer gleich der größten Disk im Array sein. Und ich weiß, es ist verlockend es RAID4 zu nennen, aber denk dran, ist es nicht. Bei einem RAID4 wird gestriped, so dass die Daten in Blöcken auf allen restlichen Disks verteilt liegen: Bei Unraid sind es aber nach wie vor einzeln formatierte Disks. Dh selbst wenn 2 Disks kaputt gehen, sind die Daten auf den restlichen Disks alle noch da (Totalausfall quasi unmöglich): Unraid unterstützt aktuell nur BTRFS bei den RAID-Leveln. ZFS ist in Planung. Warum nicht einfach mdadm und dann auch XFS angeboten wird, weiß ich nicht. Hawihoney hatte mal gefragt, aber da kam nur die Antwort, dass mdadm nicht enthalten sei:

At the moment I'm experimenting with log entries which occur extremely often and maybe should be added as a new feature to the above script: log_last=3 log_path="/var/log/syslog" while read -r count word; do echo -e "\nLast $log_last log entries which end to the word '$word' and appeared $count times:" grep "[ ']$word$" $(ls -tr "$log_path"*) | tail -n "$log_last" done < <(grep -hoP "[^ ']+$" "$log_path"* | sort | uniq -c | sort -nr | grep -P '^[ ]+[0-9]{4,}') For me it returns the following, which tells me that I should add further filtering regarding the time frame as the "worker process" do not happen anymore and maybe adding some whitelisting as "disabled state" (happens every night as I'm stopping containers to created backups) and "RAM-Disk synced" (custom entry I create on my own) log entries are expected: Last 3 log entries which end to the word '6' and appeared 3966 times: /var/log/syslog.1:Oct 30 22:36:31 thoth nginx: 2022/10/30 22:36:31 [alert] 11544#11544: worker process 19012 exited on signal 6 /var/log/syslog.1:Oct 30 22:36:33 thoth nginx: 2022/10/30 22:36:33 [alert] 11544#11544: worker process 19167 exited on signal 6 /var/log/syslog.1:Oct 30 22:36:35 thoth nginx: 2022/10/30 22:36:35 [alert] 11544#11544: worker process 19301 exited on signal 6 Last 3 log entries which end to the word 'state' and appeared 2538 times: /var/log/syslog:Nov 19 02:30:28 thoth kernel: docker0: port 5(veth9338c0f) entered disabled state /var/log/syslog:Nov 19 02:30:28 thoth kernel: docker0: port 5(veth9338c0f) entered blocking state /var/log/syslog:Nov 19 02:30:28 thoth kernel: docker0: port 5(veth9338c0f) entered forwarding state Last 3 log entries which end to the word 'synced' and appeared 2377 times: /var/log/syslog:Nov 19 11:30:01 thoth docker: RAM-Disk synced /var/log/syslog:Nov 19 12:00:01 thoth docker: RAM-Disk synced /var/log/syslog:Nov 19 12:30:01 thoth docker: RAM-Disk synced I executed the same code on a log of a broken server and it looks like this: Last 3 log entries which end to the word 'write-back' and appeared 8550 times: Nov 11 04:35:29 Tower kernel: x86/PAT: ipmiseld:4588 map pfn expected mapping type uncached-minus for [mem 0xbcdcb000-0xbcdcbfff], got write-back Nov 11 04:35:29 Tower kernel: x86/PAT: ipmiseld:4588 map pfn expected mapping type uncached-minus for [mem 0xbcdca000-0xbcdcafff], got write-back Nov 11 04:35:29 Tower kernel: x86/PAT: ipmiseld:4588 map pfn expected mapping type uncached-minus for [mem 0xbcdc9000-0xbcdc9fff], got write-back Last 3 log entries which end to the word 'failed' and appeared 4227 times: Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: shpool alloc failed Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: shpool alloc failed Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: shpool alloc failed Last 3 log entries which end to the word 'nchan_max_reserved_memory.' and appeared 4226 times: Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: nchan: Out of shared memory while allocating message of size 3623. Increase nchan_max_reserved_memory. Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: nchan: Out of shared memory while allocating message of size 4506. Increase nchan_max_reserved_memory. Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: nchan: Out of shared memory while allocating message of size 233. Increase nchan_max_reserved_memory. Last 3 log entries which end to the word 'memory' and appeared 4226 times: Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [crit] 6364#6364: ngx_slab_alloc() failed: no memory Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [crit] 6364#6364: ngx_slab_alloc() failed: no memory Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [crit] 6364#6364: ngx_slab_alloc() failed: no memory Last 3 log entries which end to the word '"localhost"' and appeared 4226 times: Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: *195093 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/var?buffer_length=1 HTTP/1.1", host: "localhost" Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: *195094 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/disks?buffer_length=1 HTTP/1.1", host: "localhost" Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: *195095 nchan: error publishing message (HTTP status code 500), client: unix:, server: , request: "POST /pub/wireguard?buffer_length=1 HTTP/1.1", host: "localhost" Last 3 log entries which end to the word '/devices' and appeared 2013 times: Nov 10 05:23:18 Tower nginx: 2022/11/10 05:23:18 [error] 6364#6364: MEMSTORE:00: can't create shared message for channel /devices Nov 10 05:23:19 Tower nginx: 2022/11/10 05:23:19 [error] 6364#6364: MEMSTORE:00: can't create shared message for channel /devices Nov 10 05:23:20 Tower nginx: 2022/11/10 05:23:20 [error] 6364#6364: MEMSTORE:00: can't create shared message for channel /devices Last 3 log entries which end to the word '/disks' and appeared 2005 times: Nov 10 05:23:19 Tower nginx: 2022/11/10 05:23:19 [error] 6364#6364: MEMSTORE:00: can't create shared message for channel /disks Nov 10 05:23:20 Tower nginx: 2022/11/10 05:23:20 [error] 6364#6364: MEMSTORE:00: can't create shared message for channel /disks Nov 10 05:23:21 Tower nginx: 2022/11/10 05:23:21 [error] 6364#6364: MEMSTORE:00: can't create shared message for channel /disks My dev server, which runs for 6 days now, returns nothing, which probably means its healthy, but I check only log entries, which appear more than 1000 times and maybe it should instead use the total size of the log file and use a variable value. Like if the log file has 1000 lines, it should return log entries which appear more than 100 times and if it has 5000 lines, than 500 times, and so on... Maybe some other users can test the code snippet and return some feedback? 😎

@Squid 1.) This is the third time, that one of my customers disabled syslog mirror to USB, because your plugin says its a bad setting. And even one customer, where I set the notification to "ignore", he disabled it, because "there was an error in the list". Is this check really needed? 2.) I like to see a new check which reports syslog entries with the word "Tainted". Those are critical kernel errors, which happen if the RAM or Storage has problems.

Konzeptioneller Fehler. Installiere stattdessen MariaDB pro Applikation neu. Spart dir auch manuelle Bastelei (neue Datenbanken anlegen usw). Genau dafür sind Container ja gedacht.

Das wenn mehr als eine Disk im Array ist. Tatsächlich ist es mit einer Disk ein klassisches RAID1. Aber das ist ja auch nichts anderes als XOR 😉 Dann BTRFS RAID1 und klar, trotzdem noch Backups vom Cache machen. Schon alleine wenn man was zurückrollen möchte. Ich sichere übrigens so: - VM oder Docker stoppen - cp --reflink=always /mnt/cache/quelle /mnt/cache/Backups/<Datum>/ziel Das dauert keine Minute und belegt keinen extra Speicherplatz. Danach schiebe ich das Backup ins Array und von da geht es dann regelmäßig an einen Remoteserver.

Keine Ahnung wie der seinen Traffic routet, aber da ist dein Problem. Frag den Container Maintainer bzw Check seine Doku.

You are not allowed to change user permissions inside of appdata. This kills every container. Did you really delete the old appdata npm folder? Use clean up appdata Plugin. Then start from the beginning. Any new SSL issue needs to be checked then.

MariaDB und Nextcloud löschen und von vorne anfangen. Vielleicht auch direkt den offiziellen Nextcloud Container nehmen.

ping 8.8.8.8 um erstmal zu prüfen, ob das Internet erreichbar ist. Das DNS dann nicht geht, ist ja die logische Konsequenz.

Wie groß darf es denn sein? Klein heißt meistens schlechte Belüftung oder schlecht erreichbare Komponenten. Daher kaufen sich viele das Define R5. Und hinlegen ist ja egal. Macht man sich eben Stofffüße an die Seitenwand.

Das geht bei keiner iGPU. Jedenfalls noch nicht gesehen, dass das jemand geschafft hätte. Jedenfalls solltest du auf deinem USB Stick eine vfio Datei finden. Die muss weg. Oder hast du noch was über die Kernel Flags eingestellt? Dann auf den Stick im Dashboard klicken und da wieder rückgängig machen.

The backup is broken somehow. How do you create it? Either it kills symlinks or it does not respect user permissions.

BTRFS ist ziemlich sensibel was Servercrash und Stromausfall anbelangt. Auch gibt es immer wieder mal Setups, wo die NVMe wohl nicht schnell genug aus dem Standby hoch kommt oder was weiß ich. Auf jeden Fall gibt es mehr Ärger mit BTRFS als mit XFS.

Did you restore your appdata through a backup or similar? As you can see it wants a symlink. Or is this file even missing?

Naja 100% wie bei jeder Parität? Nein. Der Cache ist ein separates Laufwerk was Unraid beim Upload einfach nur vor das Array setzt. Der Cache hält auch keine Dateien nach Popularität oder so vor. Du lädst was hoch und nach x Stunden verschiebt der Mover die Datei auf das Array (außer es ist ein Share, der ausschließlich auf dem Cache existieren soll). Es gibt teilweise eine große Antipathie gegenüber BTRFS. Mir eingeschlossen. Manche nehmen daher einen möglichen Datenverlust zwischen zwei Backups der NVMes in Kauf. Manche teilen dann auch zwischen Cache und Docker/VM auf. Wieder andere sichern von NVMe zu NVMe. Und dann gibt es eben noch die, die klassisch auf RAID1 setzen.

Jo, ähnlich wie bei einem RAID4, nur ohne Striping, also die Datenplatten sind einzeln formatiert.

Scheint schwieriger geworden zu sein, wenn man so die letzten Kommentare liest. Wäre aber eh nichts für mich. Ist mir zu grau die Zone 😅

Vom Prinzip irrelevant für Unraid. Der SSD Cache ist nicht wie bei ZFS oder Synology permanenten Schreibprozessen ausgesetzt. Aber klar, wenn es preislich attraktiver ist, spricht da natürlich nichts gegen. Wobei CB ja leider abhängig vom Arbeitgeber ist. Hätte ich auch gerne, konnte die Personalleitung aber noch nicht überzeugen 🤪