[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:
Anmelden, um zu antworten.

Ähnliche Themen

G
[Guide] napp-it cs, erste Schritte
2
Antworten
58
Aufrufe
4K
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