• Sicherheitsmaßnahme! Bitte ändere dein Forum-Passwort. Siehe Beitrag
  • Hardwareluxx führt derzeit die Hardware-Umfrage 2026 (mit Gewinnspiel) durch und bittet um eure Stimme. Unter allen Teilnehmern verlosen wir eine aktuelle Grafikkarte Eurer Wahl bis 1099 EUR.

[Sammelthread] napp-it cs, Web-GUI für fast jeden ZFS Server oder Servergruppen

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
iSCSI wird immer weniger wichtig und eingesetzt. Wenn nötig, wäre ein minimales Share Menü (on/off unterhalb eines Dateisystems wie in napp-it se) denkbar für OmniOS und Linux. Windows ist mit.vhdx virtual disk über SMB (Direkt) flexibler, einfacher und schneller.

Ansonst bietet napp-it cs nahezu den gleichen Funktionsumfang, teils erheblich mehr und ist für mich die Zukunft (Eine web-gui für alle OS und alle Server/Services)
Beitrag automatisch zusammengeführt:

@wegisan
Mit einer (Claude Pro) KI könnte man beide Proxmox mit napp-it live überwachen während die Replikation läuft mit genauer Analyse wo das Problem ist, samt Verbesserungsvorschlag zur Vermeidung.

Allein dafür lohnt eine KI.
 
Zuletzt bearbeitet:
@gea,
und was ist napp-it_cs.service?
Ist das noch ein alter, nicht deaktivierter Dien
Zum Vergrößern anklicken....
Das ist der systemd services erstellt durch den 'systemd-sysv-generator' welcher durch das autostart.pl indirekt angestossen wurde.
Wurde von mir NICHT manuell erstellt.

Code: 
root@vpnasrep:~# systemctl cat napp-it_cs.service
# /run/systemd/generator.late/napp-it_cs.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/napp-it_cs
Description=LSB: napp-it cs (csweb-gui) ZFS storage GUI
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/napp-it_cs start
ExecStop=/etc/init.d/napp-it_cs stop

Code: 
root@vpnasrep:~# systemctl status napp-it_cs.service
● napp-it_cs.service - LSB: napp-it cs (csweb-gui) ZFS storage GUI
     Loaded: loaded (/etc/init.d/napp-it_cs; generated)
     Active: active (running) since Tue 2026-07-14 12:18:02 CEST; 4h 2min ago
 Invocation: e23e539bd88143c8a028c569ba730a32
       Docs: man:systemd-sysv-generator(8)
      Tasks: 4 (limit: 34855)
     Memory: 191.7M (peak: 209.9M)
        CPU: 12min 1.503s
     CGroup: /system.slice/napp-it_cs.service
             ├─48618 /usr/bin/perl /opt/csweb-gui/data/cs_server/server.pl
             ├─48642 /usr/bin/perl /opt/csweb-gui/data/cs_server/monitor.pl
             ├─48657 /usr/bin/perl /opt/csweb-gui/data/cs_server/auto.pl
             └─48671 /usr/bin/perl /opt/csweb-gui/data/cs_server/webserver.pl

Jul 14 16:20:51 vpnasrep napp-it_cs[48671]: DBG    -> file=/opt/csweb-gui/data/wwwroot/cgi-bin/admin-mon.pl is_perl=1
Jul 14 16:20:51 vpnasrep napp-it_cs[48671]: DBG    serve_perl: /opt/csweb-gui/data/wwwroot/cgi-bin/admin-mon.pl method=GET body=0b
Jul 14 16:20:51 vpnasrep napp-it_cs[48671]: 2026.07.14.16.20.51  HTTP 200 GET /cgi-bin/admin-mon.pl 192.168.2.20 0ms pl
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: DBG >> 192.168.2.20 GET /cgi-bin/admin-mon.pl?id=&l1=&l2=&l3=&prop=&prop2=&list=&_=1784037194978
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: DBG    lookup: /opt/csweb-gui/_my/wwwroot/cgi-bin/admin-mon.pl
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: DBG    lookup: /opt/csweb-gui/data/wwwroot/cgi-bin/admin-mon.pl
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: DBG    found: /opt/csweb-gui/data/wwwroot/cgi-bin/admin-mon.pl (perl=1)
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: DBG    -> file=/opt/csweb-gui/data/wwwroot/cgi-bin/admin-mon.pl is_perl=1
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: DBG    serve_perl: /opt/csweb-gui/data/wwwroot/cgi-bin/admin-mon.pl method=GET body=0b
Jul 14 16:20:55 vpnasrep napp-it_cs[48671]: 2026.07.14.16.20.55  HTTP 200 GET /cgi-bin/admin-mon.pl 192.168.2.20 0ms pl

Ist das ein Problem?
Wenn man die dmesg Einträge anschaut möchte Debian 13 trixie wohl keine SYS V Scripte mehr!
Code: 
[10850.907361] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=napp-it_cs.service,mems_allowed=0,global_oom,task_memcg=/system.slice/napp-it_cs.service,task=perl,pid=34269,uid=0
[10850.908244] Out of memory: Killed process 34269 (perl) total-vm:30501544kB, anon-rss:29721684kB, file-rss:84kB, shmem-rss:0kB, UID:0 pgtables:58260kB oom_score_adj:0
[12148.827893] systemd-sysv-generator[53666]: SysV service '/etc/init.d/napp-it_cs' lacks a native systemd unit file, automatically generating a unit file for compatibility.
[12148.829515] systemd-sysv-generator[53666]: Please update package to include a native systemd unit file.
[12148.830044] systemd-sysv-generator[53666]: ! This compatibility logic is deprecated, expect removal soon. !
[12149.316154] systemd-sysv-generator[53704]: SysV service '/etc/init.d/napp-it_cs' lacks a native systemd unit file, automatically generating a unit file for compatibility.
 
in der Tat, mit Debian 13 muss der autostart wohl anders werden,

Daneben scheinen die threads in webserver RAM nicht korrekt freizugeben
ich untersuche das und mach dann ein update.
 
die neue Replikation zeigt den gleichen Effekt.
Nach ca. 17,5 min und ~ 250 GB steigt plözlich der RAM Bedarf an bis alles used ist und dann wird der perl Prozess vom kernel gekillt.
Das erfolgt auf dem Replikationsserver (Ziel mit Pull Replikation)
Auf dem Quellserver läuft es weiterhin ok.

Mit dem watch - Kommandio auf dem Replikationserver ercheinen zufällig kurz 2 server.pl Prozesse. Die Häufigkeit nimmt zu je näher OOM Kill kommt.

Danke für die Unterstützung
 
ja, der Auto-Startmechanismus muss an Debian 13 angepasst werden. Ausserdem gibts wohl ein memory problem mit admin-mon.pl (bedient die Ampel mit statusinfos) mit der Folge dass webserver abstürzt und dann der Auto Neustart für alle 4 Dienste nicht sauber läuft (daher kurz die doppelte Anzeige für den Backenddienst server.pl)

Ich denke, bis heute abend gibts ein update für beides.
 
wegisan schrieb:
die neue Replikation zeigt den gleichen Effekt.
Zum Vergrößern anklicken....

napp-it cs 26.06e
- systemd autostart in Debian 13/Proxmox
- fixes a restart problem in Debian 13
- fixes a memory problem with Ajax (admin-mon used in status ample)

Update auf console:
Code: 
curl -ksL https://www.napp-it.org/cs_setup.sh | sh

oder im Menü About > Frontend Update

/opt/csweb-gui/autostart.pl nochmal aufrufen

Gib Bescheid ob damit dir restart/crash probleme behoben sind
 
Guten Morgen gea,

neue Version installiert. Der systemd services läuft.
Leider haben wir immer noch ein Memory Problem. Die Replikation eines 570GB FS läut ungefähr bis zur Mitte.
Dann steigt der Memorybedarf wieder an beim monitor.pl. Bis er dann gekillt wird.

Code: 
Jul 15 10:48:21 vpnasrep kernel: Out of memory: Killed process 2068 (perl) total-vm:27293264kB, anon-rss:26524796kB, file-rss:8kB, shmem-rss:0kB, UID:0 pgtables:52008kB oom_score_adj:0

root@vpnasrep:~# ps -ef|grep 2068
root        2068       1  8 10:00 ?        00:04:03 /usr/bin/perl /opt/csweb-gui/data/cs_server/monitor.pl
root       17669    2331  0 10:47 pts/0    00:00:00 grep 2068

top - 10:48:03 up 47 min,  1 user,  load average: 6.65, 6.08, 4.13
Tasks: 321 total,   2 running, 319 sleeping,   0 stopped,   0 zombie
%Cpu(s): 17.7 us, 19.3 sy,  0.0 ni, 47.7 id,  8.7 wa,  0.0 hi,  6.6 si,  0.0 st
MiB Mem :  31989.2 total,   2841.9 free,  29319.9 used,    218.4 buff/cache    
MiB Swap:      0.0 total,      0.0 free,      0.0 used.   2669.4 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                        
  13604 root      20   0 1495520 267168   1548 S 111.3   0.8  13:52.37 cs-stream                                      
   2068 root      20   0   22.9g  22.2g   3816 R 100.0  71.0   4:51.25 perl                                            
  13605 root      20   0   17788   5448   3964 S  32.2   0.0   3:47.34 zfs

Es erfolgt ein Neustart der services.
Die Replikation wird abgebrochen und startet auch nicht neu. Der Jobstatus steht auf 'check'.

Manuell neu gestartet beginnt die Replikation wieder von vorn.

Update:
Habe beim manuellen Start den monitor.pl manuell gekillt. Dann läuft die Replikation weiter bis zum Ende
 
Zuletzt bearbeitet:
monitor.pl (macht cmd caching und Überwachung) scheint das Problem zu sein. Bitte monitor.pl killen und replikation neu starten um das zu verifizieren.
Beitrag automatisch zusammengeführt:

Ich habe mit den mir zur verfügung stehenden Daten ein Claude KI Codereview gemacht.
Das ist nicht so einfach weil Claude den Prozess nicht Live beobachten kann so wie bei meinen Rechnern in der Gruppe.

Es könnte sein dass zwei Probleme zusammenkommen
- monitor.pl log und cmd caching (das ist in der 26.06f entschärft)
- job-replicate job Überwachung mit timeout 80s ohne Datenänderung im Ziel
(jetzt viel längerer Timeout neben der Prozessüberwachung)

Haben wir hier eine VPN Verbindung für die Replikation?
Das könnte das Problem laut KI verschärfen (hostname legt das nahe).

Die Version 26.06f (About > Frontend Update) entschärft beide Vermutungen und verbessert logging für weitere Analyse
 
Zuletzt bearbeitet:
Replikation ist ohne Probleme durchgelaufen ohne monitor.pl. Scheint wirklich das Problem zu sein.

Nein, keine VPN Verbindung. Alles lokal im LAN. 10GB Anbindung aller Server über Mikrotik Switch.

Werde den 26.06f mal installieren und einen Replikationsjob nochmals neu starten.
Beitrag automatisch zusammengeführt:

Diesmal hat es einen Fehler kurz nach dem Start der Replikation gegeben.

Code: 
id.last — job 1784112442 (last run)
2026.07.15 12:48:30 error error: fast_end line 771: zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.15 12:48:30 step zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.15 12:48:30 step zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.15 12:48:29 step wait until next dest snap is created: repool/media@1784112442_repli_zfs_192.168.2.54_nr_1, 2 % done
2026.07.15 12:47:49 step receive cmd on 192.168.2.54 zfs send dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log >> /opt/csweb-gui/tmp/remote_1784112442_1784112466_3899.log 2>&1 &
2026.07.15 12:47:46 step start initial send to 192.168.2.55 l_1784112442 zfs send dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log &
2026.07.15 12:47:46 step start initial send to 192.168.2.55 l_1784112442 zfs send dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log &
2026.07.15 12:47:46 step send snap from 192.168.2.54 dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1
2026.07.15 12:47:46 step send snap from 192.168.2.54 dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1
2026.07.15 12:47:41 step receive cmd on 127.0.0.1 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media >> /opt/csweb-gui/tmp/remote_1784112442_1784112457_938.log 2>&1 &
2026.07.15 12:47:38 step receiver 127.0.0.1 pids 56434 ? S 0:00 zfs receive -Fv repool/media
2026.07.15 12:47:38 request ret: 56434 ? S 0:00 zfs receive -Fv repool/media
2026.07.15 12:47:37 step 672,127.0.0.1 start receiver: l_1784112442 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media &
2026.07.15 12:47:37 step 661, 127.0.0.1 start receiver: l_1784112442 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media &
2026.07.15 12:47:37 step start remote initial replication 192.168.2.54 -> 127.0.0.1
2026.07.15 12:47:37 step start remote initial replication 192.168.2.54 -> 127.0.0.1
2026.07.15 12:47:37 step lastrun=15.jul_12_47
2026.07.15 12:47:37 step 320, start remote initial replication
2026.07.15 12:47:37 step check if dest fs exists:
2026.07.15 12:47:37 step 245 check real cs-stream call via rl (remotelog or rld (delete) in web-gui cmd
2026.07.15 12:47:37 step 245 check real cs-stream call via rl (remotelog or rld (delete) in web-gui cmd
2026.07.15.12.47.37 main line 76 start job-replicate with parameter:<br>id=1784112442, action=run, par=run_1784112442

Der cs_stream läuft aber weiter.
 
Zuletzt bearbeitet:
Info, Claude KI
1784112119023.png

Beitrag automatisch zusammengeführt:

Claude KI Analyse


Code: 
Zwei Dinge fallen sofort auf:
1. Mein $info-Fix funktioniert korrekt — die finale Fehlerzeile zeigt jetzt klar "zfs receive process on 127.0.0.1 ended unexpectedly" statt einer leeren/veralteten Nachricht. ✅
2. Aber das ist vermutlich kein Timeout-Problem mehr, sondern ein echter, schneller Absturz: Nur 1 Sekunde zwischen "2 % done" (12:48:29) und "ended unexpectedly" (12:48:30) — das ist weit vor dem 15-Minuten-Backstop, es greift der primäre Check (Prozess weg). Das heißt entweder:

(a) zfs receive ist tatsächlich sehr früh (bei nur 2%) echt abgestürzt — mein Fix hat das nur schneller/klarer sichtbar gemacht, als es das alte, vage Timeout-Verhalten vorher tat. In dem Fall ist das eine echte, neue Erkenntnis, kein Bug meines Fixes.
(b) Mein ps axww | grep -E 'zfs (receive|recv)'-Check hat einen False Positive — der Prozess lief eigentlich noch, wurde aber nicht gefunden.

Um das zu unterscheiden, zwei Dinge:
Prüf bitte die beiden referenzierten Logs aus deiner eigenen id.last-Ausgabe — die sollten die eigentliche Fehlerursache von zfs receive selbst zeigen:
/opt/csweb-gui/tmp/cs-stream.log
/opt/csweb-gui/tmp/remote_1784112442_1784112466_3899.log
Und zum Ausschluss eines False-Positives in meinem Check — könntest du, falls nochmal ein Lauf passiert, während er läuft (bei "X % done") manuell auf dem Zielrechner (127.0.0.1 = dieser Host) prüfen:
bash# ps axww | grep -E 'zfs (receive|recv)' | grep -v grep
Falls das während eines laufenden Transfers nichts zurückgibt, obwohl zfs receive laut ps -ef eigentlich noch da ist, hätte meine Erkennung ein Problem (z.B. Quoting/Encoding beim &socket()-Aufruf). Falls es korrekt den Prozess zeigt, ist der Absturz real und wir müssen der eigentlichen zfs receive/cs-stream-Fehlerursache nachgehen, nicht meinem Detection-Code.
Kannst du kurz in die beiden Log-Dateien schauen?
 
Zuletzt bearbeitet:
Die Replikation wurde korrekt beendet. Snap auf dem Ziel erstellt.
Den Jobstatus 'error' habe ich mit einem weiteren 'run now' auf 'ok' gebracht.

Könnte ein einmaliger Effekt gewesen sein.

Ich werde das jetzt mal so stehen lassen und beobachten ob die aktualisierenden Replikationen laufen.
Das kann aber ein bis zwei Wochen dauern.
 
Ja, da sind drei unabhängige Vorgänge. Am Anfang startet der Job auf dem Frontend und startet dann einen send worker Job auf source und einen receive worker auf destination. Die Übertragen dann das Dateisystem selbstständig und verschlüsselt über cs-stream. Der Job Prozess selber macht dann nur noch Überwachung solange es kein hard kill des Betriebssystems für die worker jobs gibt.

Einer KI auf dem Frontend Server (auf Proxmox oder Windows mit remote members) mit file und terminalzugriff könnte man jetzt sagen, lies guideline in /opt/csweb-gui/data/howto.ai und starte die Replikation nr 123. Überwache Prozesse und logs lokal und auf source und destination. Analysiere auftretende Fehler.
 
Zuletzt bearbeitet:
hier der Inhalt der beiden logs.
zfs_send Server:
Code: 
root@vpmoxhci:/opt/csweb-gui/tmp# tail cs-stream.log
2026.07.14 11:31:11  cs-stream v2.0.0  mode=send    transferred=624 B  time=00:00  speed=220.68 KB/s  buf=128.00 MB  rate=off
2026.07.14 11:34:39  cs-stream v2.0.0  mode=send    transferred=7.26 GB  time=00:14  speed=534.36 MB/s  buf=128.00 MB  rate=off
2026.07.14 11:47:11  cs-stream v2.0.0  mode=send    transferred=195.01 GB  time=07:38  speed=436.19 MB/s  buf=128.00 MB  rate=off
2026.07.15 10:23:44  cs-stream v2.0.0  mode=send    transferred=7.74 MB  time=00:00  speed=345.40 MB/s  buf=128.00 MB  rate=off
2026.07.15 10:33:26  cs-stream v2.0.0  mode=send    transferred=135.94 GB  time=05:14  speed=443.71 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:21:18  cs-stream v2.0.0  mode=send    transferred=577.83 GB  time=24:40  speed=399.90 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:25:53  cs-stream v2.0.0  mode=send    transferred=7.26 GB  time=00:16  speed=457.70 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:35:53  cs-stream v2.0.0  mode=send    transferred=195.01 GB  time=08:00  speed=416.32 MB/s  buf=128.00 MB  rate=off
2026.07.15 13:13:38  cs-stream v2.0.0  mode=send    transferred=577.83 GB  time=25:51  speed=381.41 MB/s  buf=128.00 MB  rate=off
2026.07.15 13:16:49  cs-stream v2.0.0  mode=send    transferred=624 B  time=00:00  speed=225.58 KB/s  buf=128.00 MB  rate=off

cat remote_1784112442_1784112466_3899.log
    zfs send dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log  >> /opt/csweb-gui/tmp/remote_1784112442_1784112466_3899.log 2>&1 &
re:         
2026.07.15 12:47:46  cs-stream  connected to 192.168.2.55:52956  (buf=128.00 MB)
2026.07.15 13:13:38  cs-stream  cs-stream v2.0.0  mode=send    transferred=577.83 GB  time=25:51  speed=381.41 MB/s  buf=128.00 MB  rate=off

zfs receive Server:
Code: 
root@vpnasrep:/opt/csweb-gui/tmp# tail cs-stream.log
2026.07.14 11:47:11  cs-stream v2.0.0  mode=listen  transferred=195.01 GB  time=07:38  speed=435.89 MB/s  buf=128.00 MB  rate=off
2026.07.14 17:49:36  cs-stream v2.0.0  mode=listen  transferred=880.63 GB  time=38:30  speed=390.30 MB/s  buf=128.00 MB  rate=off
2026.07.15 10:23:45  cs-stream v2.0.0  mode=listen  transferred=7.74 MB  time=00:01  speed=8.62 MB/s  buf=128.00 MB  rate=off
2026.07.15 10:33:26  cs-stream v2.0.0  mode=listen  transferred=135.94 GB  time=05:14  speed=443.33 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:21:18  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=24:40  speed=399.81 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:25:54  cs-stream v2.0.0  mode=listen  transferred=7.26 GB  time=00:17  speed=445.48 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:35:53  cs-stream v2.0.0  mode=listen  transferred=195.01 GB  time=08:00  speed=416.11 MB/s  buf=128.00 MB  rate=off
2026.07.15 12:20:52  cs-stream v2.0.0  mode=listen  transferred=882.37 GB  time=39:47  speed=378.56 MB/s  buf=128.00 MB  rate=off
2026.07.15 13:13:38  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=25:52  speed=381.32 MB/s  buf=128.00 MB  rate=off
2026.07.15 13:16:49  cs-stream v2.0.0  mode=listen  transferred=624 B  time=00:00  speed=230.07 KB/s  buf=128.00 MB  rate=off

Das Log remote_1784112442_1784112466_3899.log gibt's auf dem Receive Server nicht.

Das Replikationslog des abgeschlossenen Jobs
Code: 
root@vpnasrep:/opt/csweb-gui/tmp# cat remote_1784112442_1784112457_938.log
    /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 52956 027685a3aeb82056fe3052138f58399927348b1e5a9c692d471de5d6d341af67 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media  >> /opt/csweb-gui/tmp/remote_1784112442_1784112457_938.log 2>&1 &
re:        
receiving full stream of dpool/smb/media@1784112442_repli_zfs_192.168.2.54_nr_1 into repool/media@1784112442_repli_zfs_192.168.2.54_nr_1
received 578G stream in 1560.56 seconds (379M/sec)

Ich werde jetzt nochmal eine komplette Replikation dieses FS auslöen.
Beitrag automatisch zusammengeführt:

also.
Code: 
root@vpnasrep:~# ps axww | grep -E 'zfs (receive|recv)' | grep -v grep
  82572 ?        S      0:52 zfs receive -Fv repool/media
root@vpnasrep:~#
root@vpnasrep:~# ps -ef | grep receive
root       82572       1 25 14:17 ?        00:00:54 zfs receive -Fv repool/media
root       82663       2  1 14:17 ?        00:00:03 [receive_writer]
root       83985    2331  0 14:20 pts/0    00:00:00 grep receive

Job im GUI auf Zielserver zeigt einen error an nachdem ich manuellen einen Refresh der Seite ausgelöst habe. Zuvor stand er auf running welchselte aber nicht auf eine 'done' Anzeige.

Job log aus dem GUI
Code: 
2026.07.15 14:17:55 error error: fast_end line 771: zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.15 14:17:55 step zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.15 14:17:55 step zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.15 14:17:55 step wait until next dest snap is created: repool/media@1784117807_repli_zfs_192.168.2.54_nr_1, 2 % done
2026.07.15 14:17:15 step receive cmd on 192.168.2.54 zfs send dpool/smb/media@1784117807_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 58331 19d040c0593cbf2388ed54577ce525a2ffe77d1dbd8897be1d7fdc9480473c6f --log=/opt/csweb-gui/tmp/cs-stream.log >> /opt/csweb-gui/tmp/remote_1784117807_1784117831_8380.log 2>&1 &
2026.07.15 14:17:11 step start initial send to 192.168.2.55 l_1784117807 zfs send dpool/smb/media@1784117807_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 58331 19d040c0593cbf2388ed54577ce525a2ffe77d1dbd8897be1d7fdc9480473c6f --log=/opt/csweb-gui/tmp/cs-stream.log &
2026.07.15 14:17:11 step start initial send to 192.168.2.55 l_1784117807 zfs send dpool/smb/media@1784117807_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 58331 19d040c0593cbf2388ed54577ce525a2ffe77d1dbd8897be1d7fdc9480473c6f --log=/opt/csweb-gui/tmp/cs-stream.log &
2026.07.15 14:17:11 step send snap from 192.168.2.54 dpool/smb/media@1784117807_repli_zfs_192.168.2.54_nr_1
2026.07.15 14:17:11 step send snap from 192.168.2.54 dpool/smb/media@1784117807_repli_zfs_192.168.2.54_nr_1
2026.07.15 14:17:06 step receive cmd on 127.0.0.1 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 58331 19d040c0593cbf2388ed54577ce525a2ffe77d1dbd8897be1d7fdc9480473c6f --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media >> /opt/csweb-gui/tmp/remote_1784117807_1784117822_8241.log 2>&1 &
2026.07.15 14:17:03 step receiver 127.0.0.1 pids 82572 ? S 0:00 zfs receive -Fv repool/media
2026.07.15 14:17:03 request ret: 82572 ? S 0:00 zfs receive -Fv repool/media
2026.07.15 14:17:02 step 672,127.0.0.1 start receiver: l_1784117807 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 58331 19d040c0593cbf2388ed54577ce525a2ffe77d1dbd8897be1d7fdc9480473c6f --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media &
2026.07.15 14:17:02 step 661, 127.0.0.1 start receiver: l_1784117807 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 58331 19d040c0593cbf2388ed54577ce525a2ffe77d1dbd8897be1d7fdc9480473c6f --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media &
2026.07.15 14:17:02 step start remote initial replication 192.168.2.54 -> 127.0.0.1
2026.07.15 14:17:02 step start remote initial replication 192.168.2.54 -> 127.0.0.1
2026.07.15 14:17:02 step lastrun=15.jul_14_17
2026.07.15 14:17:02 step 320, start remote initial replication
2026.07.15 14:17:02 step check if dest fs exists:
2026.07.15 14:17:02 step 245 check real cs-stream call via rl (remotelog or rld (delete) in web-gui cmd
2026.07.15 14:17:02 step 245 check real cs-stream call via rl (remotelog or rld (delete) in web-gui cmd
2026.07.15.14.17.02 main line 76 start job-replicate with parameter:<br>id=1784117807, action=run, par=run_1784117807

Dein check funktioniert weiterhin.
Replikation läuft weiter.
 
Zuletzt bearbeitet:
380 MB/s für Übertragung (zfs send oder filesync) in einem verschlüsselten Tunnel ist schonmal exzellent, wäre man oft froh wenn man das unverschlüsselt hat. Die Logs sagen ansonst nur dass alles ok gelaufen ist, man bräuchte logs im Fehlerfall.
 
Replikation wurde korrekt abgeschlossen.
Mit einem zusätzlichen 'run now' steht der Job jetzt wieder auf ok.
Was mir noch aufgefallen ist:
Nach dem die Replikation abgeschlossen war belegten die napp-it_cs services immer noch ca. 7 GB Memory.
Ein restart der Services hat diese dann freigeben?

Werde das nun etwas beobachten.
 
KI Analyse

Code: 
Sehr wertvolle Beobachtung — das ist der bisher konkreteste Beweis für das Leck, den wir haben: ~7 GB durch einen einzelnen Replikations-Lauf, freigegeben erst durch Neustart. Das ist deutlich gezielter als die bisherigen Tage-langen OOM-Fälle.
Gut auch: der Job steht nach manuellem "run now" wieder auf "ok" — der frühere "ended unexpectedly"-Fall war also kein dauerhafter Blocker.
Um das Leck jetzt wirklich zu lokalisieren, brauche ich noch eine Angabe: welcher der vier Dienste hat die ~7 GB gehalten? Falls du das noch prüfen kannst (auch rückwirkend interessant, falls du es dir vor dem Neustart notiert hattest, oder beim nächsten Mal):

ps aux --sort=-rss | grep -E 'server.pl|monitor.pl|auto.pl|webserver.pl' | grep -v grep
 
ich würde behaupten aus den beiden Auszügen ist der webserver Prozess: 74128

Code: 
top - 14:44:49 up  4:44,  1 user,  load average: 0.37, 2.60, 3.05
Tasks: 313 total,   1 running, 312 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.2 us,  0.1 sy,  0.0 ni, 99.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  31989.2 total,  21610.9 free,  10577.1 used,    166.1 buff/cache     
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  21412.2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                   
  74128 root      20   0  693456 284016   7996 S   1.7   0.9   2:49.49 perl                                                                                       
    397 root      39  19       0      0      0 S   0.3   0.0   0:00.02 dp_zil_clean_ta                                                                           
  69759 www-data  20   0  239648 159720   7184 S   0.3   0.5   0:04.01 pveproxy worker                                                                           
      1 root      20   0   24868   7708   3012 S   0.0   0.0   0:02.85 systemd                                                                                   
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.45 kthreadd                                                                                   
      3 root      20   0       0      0      0 S   0.0   0.0   0:00.00 pool_workqueue_release                                                                     
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-rcu_gp                                                                           
      5 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-sync_wq                                                                         
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-kvfree_rcu_reclaim                                                               
      7 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker/R-slub_flushwq

Code: 
systemctl status napp-it_cs.service
● napp-it_cs.service - napp-it cs (csweb-gui) ZFS storage GUI
     Loaded: loaded (/etc/systemd/system/napp-it_cs.service; enabled; preset: enabled)
     Active: active (exited) since Wed 2026-07-15 13:42:58 CEST; 1h 2min ago
 Invocation: d0cfbc9980974f2d8773389653f97539
    Process: 74026 ExecStart=/usr/bin/perl /opt/csweb-gui/start.pl 1 (code=exited, status=0/SUCCESS)
   Main PID: 74026 (code=exited, status=0/SUCCESS)
      Tasks: 4 (limit: 34855)
     Memory: 7.3G (peak: 7.7G)
        CPU: 37min 22.667s
     CGroup: /system.slice/napp-it_cs.service
             ├─74073 /usr/bin/perl /opt/csweb-gui/data/cs_server/server.pl
             ├─74097 /usr/bin/perl /opt/csweb-gui/data/cs_server/monitor.pl
             ├─74110 /usr/bin/perl /opt/csweb-gui/data/cs_server/auto.pl
             └─74128 /usr/bin/perl /opt/csweb-gui/data/cs_server/webserver.pl
 
Frage:
Hab 2mal NappIT SE auf OmniOS.

Bei dem einen werden mir die Temperaturen der SATA HDDs unter "Disk" angezeigt, zwar nicht immer zuverlässig, manchmal muss man die Seite neuladen aber es klappt am Ende.

In dem anderen Rechner werkeln 2 SATA SSDs, hier werden nie Temperaturen angezeigt, wenn man sich die Smartwerte ausliest findet man dort aber auch den Temp Wert.

Bin mir nicht mehr 100Prozentig sicher aber als ich einmal NVMe hatte war es meine ich auch so dass keine Temperaturen angezeigt wurden.

Alles softwaretechnisch auf dem aktuellen Stand.

Gibt es da zwischen HDDs und SSD einen unterschiedlich bezüglich Temp Sensoren?

Hardware ist einmal HP Microserver Gen8 und einmal HP Microserver Gen10Plus. Einmal "Baremetal" bei dem anderen als VM aber SATA Controller durchgereicht an OmniOS. Nicht angezeigt werden sie in dem Rechner wo OmniOS und Nappit direkt auf der Maschine laufen. Über Smart wie gesagt auslesbar nur in der Anzeige im Menü Disk tauchen sie nicht auf.
 
CommanderBond schrieb:
Gibt es da zwischen HDDs und SSD einen unterschiedlich bezüglich Temp Sensoren?
Zum Vergrößern anklicken....
Da bräuchte ich die smartctl Werte der funktionierenden und der nichtfunktionierenden Platte,
Leider verhalten sich Platten verschiedener Hersteller oft anders und brauchen eine Extra Behandlung
Beitrag automatisch zusammengeführt:

napp-it cs_26.06g_rc

- bug in monitor.pl cmd caching behoben
- mehrere Optimierungen um Resourcen-Verbrauch zu reduzieren,
- Bulk Verarbeitung bei async Anzeige von Properties

Ich muss mir das morgen nochmal genauer ansehen, aber das akute Problem (hoher RAM Verbrauch) ist hoffentlich behoben
 
Zuletzt bearbeitet:
Oxh habe nochmal lang laufende Stresstests mit webserver durchgeführt und darauf aufbauend den webserver und monitor Service optimiert
Das Problem mit steigender RAM Nutzung sollte damit erledigt sein.

26.06i
- import repli, snap and scrub jobs from napp-it SE (incre,ental replications can continue)
- webserver.pl modification to reduce and limit RSS under heavy load
- guards to restart webserver and monitor service if RSS RAM consumption unexpected too high
 
Zuletzt bearbeitet:
Guten Tag gea,

ich habe jetzt die letzte Version 26.06i installiert und den Rep. JOb mit 570 GB neu gestartet.
Ist gut durchgelaufen ohne Memory Probleme. Scheint dass es mit dieser Verison ok ist.

Ein Problem besteht aber noch.
Die Job Webseite des Replikationsziel zeigt 'running' an und dann keine Änderung mehr (kein auto refresh).
Nach einigen Minuten habe ich dann die Webseite manuell neu geladen und der Job war auf error.
Gemäss log ist das nach ca. 15s passiert.
Wäre schön wenn das wie früher wieder korrekt ablaufen würde.

Hier das Joblog.
Code: 
2026.07.19 09:46:02 error error: fast_end line 784: zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.19 09:46:02 step zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.19 09:46:02 step zfs receive process on 127.0.0.1 ended unexpectedly
2026.07.19 09:46:02 step wait until next dest snap is created: repool/media@1784447089_repli_zfs_192.168.2.54_nr_1, 2 % done
2026.07.19 09:45:22 step receive cmd on 192.168.2.54 zfs send dpool/smb/media@1784447089_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log >> /opt/csweb-gui/tmp/remote_0_1784447119_6149.log 2>&1 &
2026.07.19 09:45:19 step start initial send to 192.168.2.55 l_1784447089 zfs send dpool/smb/media@1784447089_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log &
2026.07.19 09:45:19 step start initial send to 192.168.2.55 l_1784447089 zfs send dpool/smb/media@1784447089_repli_zfs_192.168.2.54_nr_1 | /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream send 192.168.2.55 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log &
2026.07.19 09:45:19 step send snap from 192.168.2.54 dpool/smb/media@1784447089_repli_zfs_192.168.2.54_nr_1
2026.07.19 09:45:19 step send snap from 192.168.2.54 dpool/smb/media@1784447089_repli_zfs_192.168.2.54_nr_1
2026.07.19 09:45:14 step receive cmd on 127.0.0.1 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media >> /opt/csweb-gui/tmp/remote_0_1784447110_7227.log 2>&1 &
2026.07.19 09:45:11 step receiver 127.0.0.1 pids 878458 ? S 0:00 zfs receive -Fv repool/media
2026.07.19 09:45:11 request ret: 878458 ? S 0:00 zfs receive -Fv repool/media
2026.07.19 09:45:10 step 672,127.0.0.1 start receiver: l_1784447089 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media &
2026.07.19 09:45:10 step 661, 127.0.0.1 start receiver: l_1784447089 /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media &
2026.07.19 09:45:10 step start remote initial replication 192.168.2.54 -> 127.0.0.1
2026.07.19 09:45:10 step start remote initial replication 192.168.2.54 -> 127.0.0.1
2026.07.19 09:45:10 step lastrun=19.jul_09_45
2026.07.19 09:45:10 step 320, start remote initial replication
2026.07.19 09:45:10 step check if dest fs exists:
2026.07.19 09:45:10 step 245 check real cs-stream call via rl (remotelog or rld (delete) in web-gui cmd
2026.07.19 09:45:10 step 245 check real cs-stream call via rl (remotelog or rld (delete) in web-gui cmd
 
Remote und ohne lokalen Zugriff nicht so einfach zu analysieren.
Claude KI gibt folgende Einschätzung

Code: 
Ohne die Detail-Logs (remote_0_1784447110_7227.log = zfs receive, remote_0_1784447119_6149.log = zfs send, cs-stream.log) kann ich die genaue Ursache nicht sicher bestimmen — nur den Job-Log seh ich hier, nicht die eigentliche Fehlerausgabe von zfs receive selbst. Aber ein paar Auffälligkeiten und meine Einschätzung:
Zeitlicher Ablauf:

09:45:10 — Receiver gestartet (cs-stream listen 57621 ... | zfs receive -Fv repool/media)
09:45:19 — Sender gestartet (zfs send ... | cs-stream send 192.168.2.55 57621 ...)
09:46:02 — nach ~40 Sekunden, bei nur 2% done, stirbt der zfs receive-Prozess "unexpectedly"

Wahrscheinlichste Ursachen, in Reihenfolge:

Zielseitig: Platz/Quota auf repool/media — häufigste Ursache für plötzlich sterbende zfs receive-Prozesse bei niedrigem Prozentsatz. Prüfen: zfs list -o space repool/media bzw. repool.
cs-stream-Tunnel bricht ab — Netzwerk-Hänger/Firewall/Timeout zwischen den Hosts. Der cs-stream.log sollte zeigen, ob die Verbindung sauber geschlossen wurde oder abrupt abriss.
Konflikt auf Zieldataset — z.B. repool/media existiert bereits mit abweichenden Snapshots/Properties, und -F (force rollback) scheitert an einem Lock oder einer laufenden Nutzung des Datasets (z.B. gemountet/in Benutzung via SMB gerade während des Rollbacks).
Sender bricht ab (Quelle: dpool/smb/media) — wenn der Sender selbst crasht/das Snapshot verschwindet, sieht der Empfänger das als unerwarteten Verbindungsabbruch.

Bitte prüfen:
tail -50 /opt/csweb-gui/tmp/remote_0_1784447110_7227.log
tail -50 /opt/csweb-gui/tmp/cs-stream.log
zfs list -o space repool
Die erste Datei zeigt vermutlich die eigentliche zfs receive-Fehlermeldung (z.B. "out of space", "dataset is busy", "cannot receive..."). Wenn du mir den Inhalt schickst, kann ich die Ursache konkret eingrenzen statt zu raten.

Mit KI und lokalen Agenten (Zugriff auf /opt und ssh) könnte man jjetzt sagen:
Starte job 123, und analysiere Fehler, mache Vorschläge zum Beseitigen.
 
Zuletzt bearbeitet:
hier die Daten dazu:
Code: 
root@vpnasrep:~# tail -50 /opt/csweb-gui/tmp/remote_0_1784447110_7227.log
    /opt/csweb-gui/data/cs_server/tools/cs-stream/linux.amd64/cs-stream listen 57621 bce7c9ad959ec31559f88258659e2e9d3359776a94539bc8ad3d6e3f6d69a050 --log=/opt/csweb-gui/tmp/cs-stream.log | zfs receive -Fv repool/media  >> /opt/csweb-gui/tmp/remote_0_1784447110_7227.log 2>&1 &
re:         
receiving full stream of dpool/smb/media@1784447089_repli_zfs_192.168.2.54_nr_1 into repool/media@1784447089_repli_zfs_192.168.2.54_nr_1
received 578G stream in 1505.95 seconds (393M/sec)
root@vpnasrep:/opt/csweb-gui/tmp# ls -ltr remote_0_1784447110_7227.log
-rw-r--r-- 1 root root 472 Jul 19 10:10 remote_0_1784447110_7227.log

Code: 
root@vpnasrep:/opt/csweb-gui/tmp# tail -50 /opt/csweb-gui/tmp/cs-stream.log
2026.07.14 10:30:04  cs-stream v2.0.0  mode=listen  transferred=844.54 GB  time=37:18  speed=386.45 MB/s  buf=128.00 MB  rate=off
2026.07.14 10:44:27  cs-stream v2.0.0  mode=listen  transferred=7.73 MB  time=00:00  speed=25.89 MB/s  buf=128.00 MB  rate=off
2026.07.14 10:55:39  cs-stream v2.0.0  mode=listen  transferred=135.94 GB  time=05:18  speed=437.43 MB/s  buf=128.00 MB  rate=off
2026.07.14 11:23:35  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=24:16  speed=406.27 MB/s  buf=128.00 MB  rate=off
2026.07.14 11:31:11  cs-stream v2.0.0  mode=listen  transferred=624 B  time=00:00  speed=226.03 KB/s  buf=128.00 MB  rate=off
2026.07.14 11:34:39  cs-stream v2.0.0  mode=listen  transferred=7.26 GB  time=00:14  speed=534.18 MB/s  buf=128.00 MB  rate=off
2026.07.14 11:47:11  cs-stream v2.0.0  mode=listen  transferred=195.01 GB  time=07:38  speed=435.89 MB/s  buf=128.00 MB  rate=off
2026.07.14 17:49:36  cs-stream v2.0.0  mode=listen  transferred=880.63 GB  time=38:30  speed=390.30 MB/s  buf=128.00 MB  rate=off
2026.07.15 10:23:45  cs-stream v2.0.0  mode=listen  transferred=7.74 MB  time=00:01  speed=8.62 MB/s  buf=128.00 MB  rate=off
2026.07.15 10:33:26  cs-stream v2.0.0  mode=listen  transferred=135.94 GB  time=05:14  speed=443.33 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:21:18  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=24:40  speed=399.81 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:25:54  cs-stream v2.0.0  mode=listen  transferred=7.26 GB  time=00:17  speed=445.48 MB/s  buf=128.00 MB  rate=off
2026.07.15 11:35:53  cs-stream v2.0.0  mode=listen  transferred=195.01 GB  time=08:00  speed=416.11 MB/s  buf=128.00 MB  rate=off
2026.07.15 12:20:52  cs-stream v2.0.0  mode=listen  transferred=882.37 GB  time=39:47  speed=378.56 MB/s  buf=128.00 MB  rate=off
2026.07.15 13:13:38  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=25:52  speed=381.32 MB/s  buf=128.00 MB  rate=off
2026.07.15 13:16:49  cs-stream v2.0.0  mode=listen  transferred=624 B  time=00:00  speed=230.07 KB/s  buf=128.00 MB  rate=off
2026.07.15 14:42:08  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=24:56  speed=395.41 MB/s  buf=128.00 MB  rate=off
2026.07.15 14:46:58  cs-stream v2.0.0  mode=listen  transferred=624 B  time=00:00  speed=213.97 KB/s  buf=128.00 MB  rate=off
2026.07.19 10:10:17  cs-stream v2.0.0  mode=listen  transferred=577.83 GB  time=24:58  speed=395.10 MB/s  buf=128.00 MB  rate=off

Code: 
root@vpnasrep:/opt/csweb-gui/tmp# zfs list -o space repool
NAME    AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
repool  14.0T  3.30T        0B    186K          1.57T      1.73T
Beitrag automatisch zusammengeführt:

hier noch was aus dem error.log auf vpnasrep:

Code: 
2026.07.19.09.39.50    STARTUP    server.pl ver=26.07.15_16:55    os=Linux 7.0.14-4-pve x86_64
2026.07.19.09.40.29    STARTUP    server.pl ver=26.07.15_16:55    os=Linux 7.0.14-4-pve x86_64
2026.07.19.09.40.46    928    b64cmd:... (::::localhost~127.0.0.1::::::::::::::nocache::1784446846::127.0.0.1_type_optcsweb-gui_92 [type /opt/csweb-gui\_cfg\appliance.log]    ->    /opt/csweb-gui_cfgappliance.log: not found
2026.07.19.09.45.10    928    b64cmd:... (::::::::::::::::::nocache::1784447110::127.0.0.1_zfs_list_-H_-r_-o_na_0f13bc82871613d39f [zfs list -H -r -o name -t snapshot filter:=_repli]    ->    cannot open 'filter:=_repli': invalid character '=' in name
Beitrag automatisch zusammengeführt:

Uups, könnte das die Ursache sein?

Code: 
  pool: repool
 state: ONLINE
status: One or more devices are faulted in response to persistent errors.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
    repaired.
  scan: resilvered 4.27G in 00:24:39 with 0 errors on Thu Jul 16 10:26:38 2026
config:

    NAME                        STATE     READ WRITE CKSUM
    repool                      ONLINE       0     0     0
      raidz1-0                  ONLINE       0     0     0
        wwn-0x50014ee2b971b00a  FAULTED      3   464     0  too many errors
        wwn-0x50014ee266843087  ONLINE       0     0     0
        wwn-0x5000c500c5376bc8  ONLINE       0     0     0
        wwn-0x50014ee266859645  ONLINE       0     0     0

errors: No known data errors
 
Zuletzt bearbeitet:
bitte bestätigen: Ist der Job durchgelaufen? (Ziel mit Snap nr1 existiert?)

KI Analyse

Code: 
 die Logs zeigen einen Fehlalarm, keinen echten Abbruch:
Was tatsächlich passiert ist:

remote_0_1784447110_7227.log (der echte zfs receive): received 578G stream in 1505.95 seconds (393M/sec) — erfolgreich abgeschlossen, Dateidatum 10:10 Uhr
cs-stream.log: 2026.07.19 10:10:17 ... transferred=577.83 GB time=24:58 speed=395.10 MB/s — exakt deckungsgleich, auch erfolgreich

Der Transfer lief also ~25 Minuten und kam sauber durch. Aber der Job meldete den Fehler schon um 09:46:02, nur ~40 Sekunden nach Start, bei "2% done" — zu diesem Zeitpunkt lief die Übertragung noch völlig normal im Hintergrund weiter.
Das sieht nach einem Fehlalarm im Polling/Monitoring-Mechanismus aus, nicht nach einem echten Abbruch.
Möglicher Zusammenhang gefunden — ein zweiter, separater Bug im selben Log:
zfs list -H -r -o name -t snapshot filter:=_repli
→ cannot open 'filter:=_repli': invalid character '=' in name
Das sieht nach einem kaputten Parameter aus — ein Filter-Argument, das fälschlich als literaler Snapshot-Name an zfs list übergeben wird (filter:=_repli statt eines echten Filterausdrucks). Wenn der Job-Prozess genau diesen fehlerhaften zfs list-Aufruf nutzt, um zu prüfen "ist der Ziel-Snapshot schon da / lebt der Receive-Prozess noch", würde dieser Check immer fehlschlagen — und das könnte fälschlich als "Prozess unerwartet beendet" interpretiert werden, obwohl der eigentliche Transfer im Hintergrund völlig gesund weiterlief.
Meine Vermutung als Ursache: ein Bug in der Fortschritts-/Fertigstellungs-Prüfung (zfs list ... filter:=...), nicht im eigentlichen Send/Receive. Soll ich mir den entsprechenden Code (vermutlich job-replicate.pl o.ä., der Filter-String-Konstruktion für diesen zfs list-Aufruf) anschauen, um die genaue Stelle zu finden?
 
Ein Auftrag an Claude: "Anlysiere Replikationsscript" auf Probleme, die zu den Logs passen:, ergab
Code: 
Das Problem: kein Unterschied zwischen "Check lief durch, Prozess wirklich weg" und "Check selbst ist fehlgeschlagen"
(Netzwerk-Hänger, Socket-Timeout, Ziel kurz beschäftigt beim Start eines großen Transfers).
Bei diesem Job war die zeitliche Nähe verräterisch: Abbruch nach nur ~40 Sekunden, bei 2% —
genau der Moment kurz nach Start, wo der Receiver-Prozess evtl. noch nicht vollständig hochgefahren war oder
das Ziel unter der initialen I/O-Last kurz nicht antwortete.

Der eigentliche Transfer lief nachweislich unbeeinträchtigt weiter und wurde nach 25 Minuten sauber abgeschlossen
—der Abbruch war also ein reiner Fehlalarm, kein echtes Prozess-Ende.


Vorschlag: Vor dem Abbruch einen kurzen Retry einbauen (z.B. 3-5s warten, nochmal prüfen), statt bei einem einzigen
negativen Check sofort zu terminieren — würde genau diese Art von False-Positive verhindern.
Soll ich das einbauen?

Ja

Zusammenfassung
Bug 1 (Hauptursache des Problems): an allen 4 Stellen, wo job-replicate.pl prüft ob der zfs receive-Prozess auf dem Ziel noch lebt,
wird jetzt bei einem negativen Ergebnis einmal mit 4s Pause nachgeprüft, bevor der Job abgebrochen wird —
verhindert False-Positives durch einen kurzen Check-Hänger (genau wie im Fall: Abbruch nach 40s bei 2%,
während der Transfer nachweislich sauber weiterlief und nach 25 Min erfolgreich fertig wurde).

Bug 2 (unabhängig gefunden): my_del_snap() (Aufräumen alter Replikations-Snapshots auf dem Ziel) hatte eine
komplett ungültige zfs list-Syntax (filter:=_repli als literales, kaputtes Argument) — dieser Aufruf ist immer fehlgeschlagen,
alte Snapshots wurden nie bereinigt. Entfernt; die eigentliche Filterung passiert ohnehin schon korrekt im Perl-Code darunter.

Beide Fixes nur in job-replicate.pl (Backend-Script, kein server.pl) — kein Backend-Restart nötig.


bitte auf Frontend Server ersetzen \opt\csweb-gui\data\menues\_lib\windows\scripts\job-replicate.pl
Beitrag automatisch zusammengeführt:

wegisan schrieb:
Uups, könnte das die Ursache sein?

Code: 
  pool: repool
 state: ONLINE
status: One or more devices are faulted in response to persistent errors.
    Sufficient replicas exist for the pool to continue functioning in a
    degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
    repaired.
  scan: resilvered 4.27G in 00:24:39 with 0 errors on Thu Jul 16 10:26:38 2026
config:

    NAME                        STATE     READ WRITE CKSUM
    repool                      ONLINE       0     0     0
      raidz1-0                  ONLINE       0     0     0
        wwn-0x50014ee2b971b00a  FAULTED      3   464     0  too many errors
        wwn-0x50014ee266843087  ONLINE       0     0     0
        wwn-0x5000c500c5376bc8  ONLINE       0     0     0
        wwn-0x50014ee266859645  ONLINE       0     0     0

errors: No known data errors
Zum Vergrößern anklicken....

Ja, dieses Problem wird dazu führen, dass der Pool viel langsamer wird (read retry bis error).
Damit wird es wahrscheinlicher dass die Jobüberwachung error meldet.
Beitrag automatisch zusammengeführt:

Übrigens: KI als Helpdesk Tool

Ist allen bewusst, dass mit KI hier die Zeit vom Problembericht mit sehr unklarem Fehlerlog bis zur Lösung (Bestätigung steht noch aus) nur ca 1h vergangen ist. Mit lokal eingerichteter Claude KI hätte man das Problem in 5min selbst gefunden und behoben, (Trainingsdaten für napp-it cs und KI liegen ja bei)
 

Anhänge

  • job-replicate.zip
    21,6 KB · Aufrufe: 4
Zuletzt bearbeitet:
job-replicate ist ersetzt.
Ich werde aber erst die HD ersetzen bevor ich den replicate job neu starte. Nicht damit mir noch der Pool flöten geht wenn noch eine Platte ausfällt.

Melde mich wieder wenn die neue Platte drin ist.
 
Anmelden, um zu antworten.

Ähnliche Themen

G
[Guide] napp-it cs, erste Schritte
2
Antworten
58
Aufrufe
5K
gea
G
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh