12.3 + Amanda -> und ewig hängt das Murmeltier

peterle

Forenkasper
Nachdem ich etwas überraschend, aber erfreulicherweise doch noch lebe, habe ich mich mal ans aufräumen begeben. FreeBSD läuft ja super, wenn es denn einmal läuft und man braucht eigentlich nie irgendwas irgendwo zu machen, wenn einem nicht die Hardware stirbt oder man ein Update macht ... :p

Also gesagt getan und bei der Gelegenheit AMANDA neu aufgesetzt und siehe da es hängt. Erst mit 12.2 und mit 12.3 aber dooferweise auch.

Der Server startet die Sicherung und dann braucht er was und dann verabschiedet er sich mit "Broken Pipe" und ist mit Nichts mehr erreichbar, nicht mit SSH, nicht mit einem einfachen Ping und auch nicht mit http. Zugang gibt es erst wieder mit einem Hardware Reset.

Die Logs, sagen nichts oder zumindest sehe ich nichts, Überwachungsorgien mit procstat, top etc. bringen auch nichts auffälliges zu Tage. Smartctl ist unverdächtig, memtest ebenfalls. ZFS Arc habe ich hoffnungsvoll auf die Hälfte des RAM im max gestellt - ohne Erfolg.

Ich hoffe und freue mich wie immer über alle Tips, Gedanken, Hinweise, Lösungen. :p

dmesg:
Code:
---<<BOOT>>---
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.3-RELEASE-p5 GENERIC amd64
FreeBSD clang version 10.0.1 (git@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2)
VT(vga): resolution 640x480
CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (3400.07-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7fbae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 34359738368 (32768 MB)
avail memory = 33287684096 (31745 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I>
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
random: unblocking device.
ioapic0 <Version 2.0> irqs 0-23 on motherboard
Launching APs: 1 7 6 5 2 3 4
Timecounter "TSC-low" frequency 1700034782 Hz quality 1000
random: entropy device external interface
WARNING: Device "g_ctl" is Giant locked and may be deleted before FreeBSD 14.0.
000.000017 [4337] netmap_init               netmap: loaded module
WARNING: Device "pci" is Giant locked and may be deleted before FreeBSD 14.0.
[ath_hal] loaded
module_register_init: MOD_LOAD (vesa, 0xffffffff811848b0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 14.0.
kbd1 at kbdmux0
mlx5en: Mellanox Ethernet driver 3.6.0 (December 2020)
nexus0
vtvga0: <VT VGA driver> on motherboard
cryptosoft0: <software crypto> on motherboard
acpi0: <ALASKA A M I> on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 550
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 1.0 on pci0
pci1: <ACPI PCI bus> on pcib1
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7800000-0xf7bfffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
pci0: <simple comms> at device 22.0 (no driver attached)
ehci0: <Intel Panther Point USB 2.0 controller> mem 0xf7d08000-0xf7d083ff irq 23 at device 26.0 on pci0
usbus0: EHCI version 1.0
usbus0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
hdac0: <Intel Panther Point HDA Controller> mem 0xf7d00000-0xf7d03fff irq 22 at device 27.0 on pci0
pcib2: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci2: <ACPI PCI bus> on pcib2
pcib3: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
pci3: <ACPI PCI bus> on pcib3
re0: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xe000-0xe0ff mem 0xf0004000-0xf0004fff,0xf0000000-0xf0003fff irq 16 at device 0.0 on pci3
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: Chip rev. 0x48000000
re0: MAC rev. 0x00000000
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S/8211 1000BASE-T media interface> PHY 1 on miibus0
rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: Ethernet address: 50:46:5d:9f:ff:f2
re0: netmap queues/slots: TX 1/256, RX 1/256
pcib4: <ACPI PCI-PCI bridge> irq 18 at device 28.6 on pci0
pci4: <ACPI PCI bus> on pcib4
ahci0: <Marvell 88SE9172 AHCI SATA controller> port 0xd040-0xd047,0xd030-0xd033,0xd020-0xd027,0xd010-0xd013,0xd000-0xd00f mem 0xf7c10000-0xf7c101ff irq 18 at device 0.0 on pci4
ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ehci1: <Intel Panther Point USB 2.0 controller> mem 0xf7d07000-0xf7d073ff irq 23 at device 29.0 on pci0
usbus1: EHCI version 1.0
usbus1 on ehci1
usbus1: 480Mbps High Speed USB v2.0
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
ahci1: <Intel Panther Point AHCI SATA controller> port 0xf0b0-0xf0b7,0xf0a0-0xf0a3,0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xf7d06000-0xf7d067ff irq 19 at device 31.2 on pci0
ahci1: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
ahcich2: <AHCI channel> at channel 0 on ahci1
ahcich3: <AHCI channel> at channel 1 on ahci1
ahcich4: <AHCI channel> at channel 2 on ahci1
ahcich5: <AHCI channel> at channel 3 on ahci1
ahcich6: <AHCI channel> at channel 4 on ahci1
ahcich7: <AHCI channel> at channel 5 on ahci1
ahciem0: <AHCI enclosure management bridge> on ahci1
acpi_button0: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
acpi_tz1: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
orm0: <ISA Option ROMs> at iomem 0xc0000-0xce7ff,0xcf000-0xcffff pnpid ORM0000 on isa0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
Timecounters tick every 1.000 msec
hdacc0: <Realtek ALC892 HDA CODEC> at cad 0 on hdac0
hdaa0: <Realtek ALC892 Audio Function Group> at nid 1 on hdacc0
pcm0: <Realtek ALC892 (Rear Analog 7.1/2.0)> at nid 20,22,21,23 and 24,26 on hdaa0
pcm1: <Realtek ALC892 (Front Analog)> at nid 27 and 25 on hdaa0
pcm2: <Realtek ALC892 (Rear Digital)> at nid 30 on hdaa0
pcm3: <Realtek ALC892 (Onboard Digital)> at nid 17 on hdaa0
hdacc1: <Intel Panther Point HDA CODEC> at cad 3 on hdac0
hdaa1: <Intel Panther Point Audio Function Group> at nid 1 on hdacc1
pcm4: <Intel Panther Point (HDMI/DP 8ch)> at nid 5 on hdaa1
pcm5: <Intel Panther Point (HDMI/DP 8ch)> at nid 7 on hdaa1
ugen1.1: <Intel EHCI root HUB> at usbus1
ugen0.1: <Intel EHCI root HUB> at usbus0
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: Root mount waiting for:<Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
 usbus0 CAM usbus1
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
ada0 at ahcich4 bus 0 scbus4 target 0 lun 0
ada0: <HGST HUS726060ALE610 APGNTD05> ACS-2 ATA SATA 3.x device
ada0: Serial Number K1K3Z3YD
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 5723166MB (11721045168 512 byte sectors)
ada1 at ahcich5 bus 0 scbus5 target 0 lun 0
ada1: <HGST HUS726060ALE610 APGNTD05> ACS-2 ATA SATA 3.x device
ada1: Serial Number K1K6D7TD
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 5723166MB (11721045168 512 byte sectors)
ada2 at ahcich6 bus 0 scbus6 target 0 lun 0
ada2: <HGST HUS726060ALE610 APGNTD05> ACS-2 ATA SATA 3.x device
ada2: Serial Number K1K7K87D
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada2: Command Queueing enabled
ada2: 5723166MB (11721045168 512 byte sectors)
ada3 at ahcich7 bus 0 scbus7 target 0 lun 0
ada3: <HGST HUS726060ALE610 APGNTD05> ACS-2 ATA SATA 3.x device
ada3: Serial Number K1K7K9BD
ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada3: Command Queueing enabled
ada3: 5723166MB (11721045168 512 byte sectors)
ses0 at ahciem0 bus 0 scbus8 target 0 lun 0
ses0: <AHCI SGPIO Enclosure 2.00 0001> SEMB S-E-S 2.00 device
ses0: SEMB SES Device
ses0: ada0,pass0 in 'Slot 02', SATA Slot: scbus4 target 0
ses0: ada1,pass1 in 'Slot 03', SATA Slot: scbus5 target 0
ses0: ada2,pass2 in 'Slot 04', SATA Slot: scbus6 target 0
ses0: ada3,pass3 in 'Slot 05', SATA Slot: scbus7 target 0
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
Root mount waiting for: usbus0 usbus1
ugen1.2: <vendor 0x8087 product 0x0024> at usbus1
uhub2 on uhub0
uhub2: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus1
ugen0.2: <vendor 0x8087 product 0x0024> at usbus0
uhub3 on uhub1
uhub3: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on usbus0
Root mount waiting for: usbus0 usbus1
uhub3: 6 ports with 6 removable, self powered
uhub2: 8 ports with 8 removable, self powered
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
lo0: link state changed to UP
re0: link state changed to DOWN
re0: link state changed to UP
Security policy loaded: MAC/ntpd (mac_ntpd)

zpool status:
Code:
  pool: zroot
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    zroot       ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        ada0p3  ONLINE       0     0     0
        ada1p3  ONLINE       0     0     0
        ada2p3  ONLINE       0     0     0
        ada3p3  ONLINE       0     0     0

errors: No known data errors
 
Welche Optionen sind auf dem Netzwerk-Interface gesetzt?

Rob

Meinst Du die?

Code:
# ifconfig -a
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>
    ether 50:46:5d:9f:ff:f2
    inet6 fe80::5246:5dff:fe9f:fff2%re0 prefixlen 64 scopeid 0x1
    inet 192.168.1.178 netmask 0xffffffc0 broadcast 192.168.1.191
    media: Ethernet autoselect (1000baseT <full-duplex,master>)
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
 
Bei Realtek-NICs kann es durchaus sein, dass sich die NIC ganz schlicht und ergreifend aufhängt. Mit ifconfig sieht alles gut aus, Carrier ist da und die LEDs am Switch blinken wunderschön. In der dmesg sind keine verdächtigen Meldungen. Trotzdem gehen partout keine Pakete durch. Manchmal hilft ein ifconfig re0 down ; sleep 10 ; ifconfig re0 up, da es wohl die Firmware neustartet oder so. Oft genug muss man allerdings rebooten.

Seltsamerweise scheint dieses Phänomen weniger von der NIC an sich, sondern mehr vom umgebenden System abzuhängen. Oder vielleicht auch von der nirgends wirklich kommunizierten Chip-Revision. Der Switch wäre eventuell auch ein Faktor. Zum Beispiel ist der r8169 in meinem Ryzen-Desktop zu Hause absolut unauffällig. Der r8169 im Dell-Desktop im Büro ist aber extrem zickig. Bis hin zu solchen Nettigkeiten, nach einem Ziehen und wieder Einstecken des Kabels der Link nicht wieder hochkommt.

Also wäre es vielleicht, wenn möglich, mal einen Blick wert an die (virtuelle) Konsole zu gehen und zu schauen, ob das System nicht weiterläuft und sich einfach nur die NIC aufhängt.
 
Oder vielleicht auch von der nirgends wirklich kommunizierten Chip-Revision.
Das vermute ich eher, denn ich habe 2x den r8169 in einem System (meine routerbüchse) und einer davon fing mit solchen Mucken an, als OPNSense auf FreeBSD 13 wechselte. Doch dazu gibt es ein Paket os-realtek-re. Seitdem ist wieder Ruhe und alles läuft wie geschmiert.
In der Info zum Paket heißt es:
Realtek re(4) vendor driver

This is the official driver from Realtek and can be loaded instead of
the FreeBSD driver built into the GENERIC kernel if you experience
issues with it (eg. watchdog timeouts), or your card is not supported.

Please note this driver requires a system reboot to activate.

WWW: https://www.realtek.com/en/componen...0-1000m-gigabit-ethernet-pci-express-software

Maintainer: franco@opnsense.org
Eventuell ist das was, eventuell auch nicht. Ich weiß derzeit aus dem Stehgreif nicht, wie und ob Treiber gewechselt wurden und was der vendor driver anders macht.
 
Es ist auf jeden Fall "erratisch". Vorletzte Nacht, lief es einfach durch und meldete nach ca. einer Stunde Vollzug der Sicherung und letzte Nacht, hat er sich dann einfach wieder aufgehangen. Ich hatte die Tage mal alles Mögliche an Tests in diversen Konsolen mitlaufen lassen und das war wie gesagt unverdächtig für mich.
 

Anhänge

  • Bildschirmfoto 2022-04-05 um 09.18.39.png
    Bildschirmfoto 2022-04-05 um 09.18.39.png
    90,7 KB · Aufrufe: 114
  • Bildschirmfoto 2022-04-05 um 09.19.07.png
    Bildschirmfoto 2022-04-05 um 09.19.07.png
    72,5 KB · Aufrufe: 99
  • Bildschirmfoto 2022-04-05 um 09.19.24.png
    Bildschirmfoto 2022-04-05 um 09.19.24.png
    76,1 KB · Aufrufe: 100
  • Bildschirmfoto 2022-04-05 um 09.19.46.png
    Bildschirmfoto 2022-04-05 um 09.19.46.png
    75 KB · Aufrufe: 108
  • Bildschirmfoto 2022-04-05 um 09.21.00.png
    Bildschirmfoto 2022-04-05 um 09.21.00.png
    49,7 KB · Aufrufe: 107
  • Bildschirmfoto 2022-04-05 um 09.21.22.png
    Bildschirmfoto 2022-04-05 um 09.21.22.png
    53,8 KB · Aufrufe: 110
  • Bildschirmfoto 2022-04-05 um 09.22.32.png
    Bildschirmfoto 2022-04-05 um 09.22.32.png
    86 KB · Aufrufe: 104
Was in meinen Augen etwas gegen die These mit der Netzwerkkarte spricht ist, daß ein CTRL-ALT-DEL über den Robot bei Hetzer nicht ausreicht, sondern er einen Hardware Reset braucht?
 
Was in meinen Augen etwas gegen die These mit der Netzwerkkarte spricht ist, daß ein CTRL-ALT-DEL über den Robot bei Hetzer nicht ausreicht, sondern er einen Hardware Reset braucht?
Nicht unbedingt, je nachdem wie der Soft-Reboot implementiert ist.
Ich würde an deiner Stelle auf jeden Fall mal den Netzwerktreiber aus den Ports ausprobieren.

Rob
 
@mr44er

Entspricht das dem hier unter FreeBSD 12.3?

Code:
# pkg search realtek
realtek-re-kmod-v196.04_3      Kernel driver for Realtek PCIe Ethernet Controllers
 
Der GAU ist vermutlich, den Treiber einzubinden und dann komme ich nicht mehr ran oder die Kiste startet gar nicht mehr. :p:zitter:
 
Das ist ja auch eine interessante Nachricht

Code:
Message from realtek-re-kmod-v196.04_3:

--
Add the following lines to your /boot/loader.conf
to override the built-in FreeBSD re(4) driver.

if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"

By default, the size of allocated mbufs is enough
to receive the largest Ethernet frame supported
by the card.  If your memory is highly fragmented,
trying to allocate contiguous pages (more than
4096 bytes) may result in driver hangs.
For this reason the value is tunable at boot time,
e.g. if you don't need Jumbo frames you can lower
the memory requirements and avoid this issue with:

hw.re.max_rx_mbuf_sz="2048"
 
Der Robot oder wie das rescuebumsdings heißt, funzt davon unabhängig bzw. sollte. (habe derzeit nichts bei hetzner)
Mehr als 'ne Stichflamme kann nicht kommen, von daher Versuch mach kluch. :)
 
Zwischenstand:
  • Default Treiber -> hängt und auch die Konsole hängt
  • Pkg Treiber -> läuft durch und auch die Konsole läuft durch

Mal schauen, was die nächsten Tage bringen.
 
Sehr gut, bei mir ist das jetzt 3:16PM up 11 days, 58 mins, her.
Effekte waren hier ohne Hänger, da die NICs an eine VM gereicht werden. Nur eben ohne Tätigkeit, wie Yamagi das beschrieb.
 
Mal ein Zwischenstand - die Fehler werden gefühlt weniger, treten aber immer noch auf.
Einige Tage gar keine Probleme und dann hängt Amanda und das System - ein Hardware Reset tut es. Es funktioniert wieder einige Tage und dann hängt Amanda (denn es schickt keine Mails mehr) und das System hängt vollständig. Muß dann einer gegentreten gehen. Die Logs sind weiterhin leer.

auth.log läßt vermuten, daß er um 1:10 verstorben ist und das ist ziemlich exakt die Zeit in der er mit Amanda zugange ist. Der startet um 1:15 und danach ist bis zum reset kein Bot der versucht sich einzuloggen.
 
Jetzt nehme ich mal
Code:
hw.re.max_rx_mbuf_sz="2048"

in der loader.conf dazu.

Verstehen tu ich die Problematik allerdings weiterhin leider nicht.
 
Mhm, komisch. Bei mir läufts immer noch fein:
Code:
$ uptime
 6:49PM  up 22 days,  4:31, 1 user, load averages: 1.39, 1.00, 0.88

Jene VM sagt:
Code:
re0@pci0:0:6:0:	class=0x020000 rev=0x15 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
....
re1@pci0:0:9:0:	class=0x020000 rev=0x09 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x1043 subdevice=0x8505
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
.....
root@router0:~ # sysctl -a | grep hw.re
hw.realmem: 7516192768
hw.re.max_rx_mbuf_sz: 9216
hw.re.s0_magic_packet: 0
hw.re.s5wol: 0
hw.re.phy_mdix_mode: 2
hw.re.phy_power_saving: 1
hw.re.eee_enable: 0
hw.re.prefer_iomap: 0
hw.re.msix_disable: 0
hw.re.msi_disable: 1
dev.t4nex.0.hw_revision: 2
 
Das sieht bei mir ähnlich aus, nur der mbuf liegt be
Code:
# sysctl -a | grep hw.re
hw.realmem: 34359738368
hw.re.max_rx_mbuf_sz: 2048
hw.re.s0_magic_packet: 0
hw.re.s5wol: 0
hw.re.phy_mdix_mode: 2
hw.re.phy_power_saving: 1
hw.re.eee_enable: 0
hw.re.prefer_iomap: 0
hw.re.msix_disable: 0
hw.re.msi_disable: 1
i Dir höher.
 
Mir fällt jetzt nur noch die Sache mit deaktivierter HW-Beschleunigung ein:

In deinem Beitrag #8, vorletztes Bild steht was von 'driver' bei amanda. Ich kenne die software nicht, aber kann man ausschließen, dass da treibertechnisch was eigenes implementiert ist?
 
Hm ... ich habe das nicht ganz durchgelesen, aber kann es sein, daß es dort um die Verbindung JAIL -> Hardware NIC geht?
Ich nutze keine Jail.

Amanda ist eine steinalte Backupsoftware oder besser Scriptsammlung, die eigentlich nichts anderes macht als über die Daten von einem Mount Point auf einem Client zu lesen, diese per SSH an den Server zu übertragen und dort per TAR und GZ das ganze zusammenzupacken und dann per DUMP auf ein Tape drive zu schreiben. Da man solche heute nicht mehr oder nur selten nutzt, kann er auch virtuelle tape drives und packt das letztendlich dann in Verzeichnisse auf der Festplatte. (Hier ein ca. 15TB zpool).


Ziemlich cooles Zeug, was neben zig anderen Backup Systemen, die ich über die Jahrzehnte auf den unterschiedlichsten OS genutzt habe, als einziges den Vorteil hatte, daß die Daten jederzeit mit rudimentärsten Mitteln wiederherstellbar/wiederfindbar waren.
Andere verlangten gerne dasselbe OS, dieselbe Revision Hardware oder sonst irgendeinen Quatsch.

Nur auf dem Server macht er blöderweise irgendwelche Hänger, die ich nicht mehr nachvollziehen oder provozieren kann.

Der Server macht sonst eigentlich nichts, außer einem Seafile und nginx dazu, was seit langem unauffällig vor sich hinläuft.

Ein amstatus CONFIG brachte aus dem letzten Crash noch das hier zustande:

Code:
# cat server-crash-amanda-20220415.log
Using /var/db/amanda/state/log/amdump
From Fri Apr 15 01:15:00 CEST 2022

www.hobbyschneiderin24.net:/         0  96623700k failed: process terminated while waiting for dumping
www.hobbyschneiderin24.net:/usr      0  88161570k failed: killed while dumping to tape (29513088k done (33.48%)) (1:20:06)
www.hobbyschneiderin24.net:/usr/home 0        20k finished (1:18:57)
www.hobbyschneiderin24.net:/var      0   1886470k finished (1:20:06)
www.hobbyschneiderin24.net:/var/log  0    132030k finished (1:19:26)
www.hobbyschneiderin24.net:/var/mail 0     25850k finished (1:19:11)

SUMMARY          part      real  estimated
                           size       size
partition       :   6
estimated       :   6            186829632k
flush           :   0         0k
failed          :   0                    0k           (  0.00%)
wait for dumping:   1             96623700k           ( 51.72%)
dumping to tape :   1  29513088k  88161570k ( 33.48%) ( 47.19%)
dumping         :   0         0k         0k (  0.00%) (  0.00%)
dumped          :   4   2044370k   2044362k (100.00%) (  1.09%)
wait for writing:   0         0k         0k (  0.00%) (  0.00%)
wait to flush   :   0         0k         0k (100.00%) (  0.00%)
writing to tape :   0         0k         0k (  0.00%) (  0.00%)
failed to tape  :   0         0k         0k (  0.00%) (  0.00%)
taped           :   4   2044370k   2044362k (100.00%) (  1.09%)
  tape 1        :   4   2044370k   2044370k (  0.65%) HS24Backup06 (4 chunks)
9 dumpers idle  : 0
taper 0 status: Writing www.hobbyschneiderin24.net:/usr
taper qlen: 0
network free kps:     10606
holding space   :         0k (  0.00%)
 dumper0 busy   :  0:01:21  ( 26.52%)
   taper busy   :  0:01:20  ( 26.32%)
 0 dumpers busy :  0:03:48  ( 74.41%)                   0:  0:03:48  (100.00%)
 1 dumper busy  :  0:01:18  ( 25.59%)                   0:  0:01:18  (100.00%)
#
#
# su amanda
% amstatus
amstatus [--file amdump_file]
         [--summary] [--dumping] [--waitdumping] [--waittaper]
         [--dumpingtape] [--writingtape] [--finished] [--failed]
         [--estimate] [--gestimate] [--stats] [--date]
         [--locale-independent-date-format]
         [--config] <config>
%
%
%
% amstatus HS24Backup
Using /var/db/amanda/state/log/amdump.1
From Wed Apr 20 01:15:00 CEST 2022

www.hobbyschneiderin24.net:/         0  96730480k finished (2:05:03)
www.hobbyschneiderin24.net:/usr      0  88217820k finished (1:41:41)
www.hobbyschneiderin24.net:/usr/home 0        20k finished (1:19:19)
www.hobbyschneiderin24.net:/var      0   1886440k finished (1:20:28)
www.hobbyschneiderin24.net:/var/log  0    130380k finished (1:19:48)
www.hobbyschneiderin24.net:/var/mail 0     25850k finished (1:19:32)

SUMMARY          part      real  estimated
                           size       size
partition       :   6
estimated       :   6            186990962k
flush           :   0         0k
failed          :   0                    0k           (  0.00%)
wait for dumping:   0                    0k           (  0.00%)
dumping to tape :   0                    0sunit           (  0.00%)
dumping         :   0         0k         0k (  0.00%) (  0.00%)
dumped          :   6 186990990k 186990962k (100.00%) (100.00%)
wait for writing:   0         0k         0k (  0.00%) (  0.00%)
wait to flush   :   0         0k         0k (100.00%) (  0.00%)
writing to tape :   0         0k         0k (  0.00%) (  0.00%)
failed to tape  :   0         0k         0k (  0.00%) (  0.00%)
taped           :   6 186990990k 186990962k (100.00%) (100.00%)
  tape 1        :   6 186990990k 186990990k ( 59.44%) HS24Backup07 (6 chunks)
10 dumpers idle : 0
taper 0 status: Idle
taper qlen: 0
network free kps:     80000
holding space   :         0k (  0.00%)
 dumper0 busy   :  0:45:55  ( 91.75%)
   taper busy   :  0:45:55  ( 91.75%)
 0 dumpers busy :  0:04:11  (  8.38%)                   0:  0:04:11  (100.00%)
 1 dumper busy  :  0:45:51  ( 91.62%)                   0:  0:45:51  (100.00%)
%
%
% amcheck HS24Backup
Amanda Tape Server Host Check
-----------------------------
Searching for label 'HS24Backup08':found in slot 8: volume 'HS24Backup08'
Will write to volume 'HS24Backup08' in slot 8.
NOTE: skipping tape-writable test
Server check took 0.316 seconds

Amanda Backup Client Hosts Check
--------------------------------
Client check: 1 host checked in 2.894 seconds.  0 problems found.

(brought to you by Amanda 3.3.9)
%

Interessanterweise erscheint auch bei dem aktuell gelungenen Durchlauf ein "dumper busy" und vielleicht macht das ja die Probleme.
Ich warte jetzt mal wieder ein paar Tage und schau dann weiter.

Danke fürs Mitdenken! :)
 
kann es sein, daß es dort um die Verbindung JAIL -> Hardware NIC geht?
Ja, aber die jail ist da nicht der Knackpunkt, sondern eben diese oft problemverursachende Hardwarebeschleunigung und die sieht man nicht nur mit realtek, sondern auch mal mit intel. Es könnte sogar sein, dass genau das auch das Problem mit dem Ursprungstreiber war und nicht der Treiber an sich. Randbemerkung: OPNSense hat die Beschleunigung als default deaktiviert, weil sich das in dem Wildwuchs von Chips und Revisionen nicht wirklich eingrenzen lässt. Vielleicht klappts nun auch mit kleineren chunks, man wirds sehen. Nervig ist es allemal. :)

bei dem aktuell gelungenen Durchlauf ein "dumper busy" und vielleicht macht das ja die Probleme.
Genau, process terminated while waiting for dumping riecht stark nach disk/tape down oder Netz hängt.
 
Allerdings hat die NIC wie die meisten Realtek-Chips recht wenig Hardwarebeschleunigung:

Code:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE>

VLANs sind da nicht im Spiel, Wake on LAN hat keinen Einfluss auf den täglichen Betrieb und automatisches Linkstate-Reporting ist auch nicht gerade die höchste Magie. Bleiben die beiden Checksum-Berechnungen, die es allerdings auch schon seit den 90ern gibt. Ich würde sie mal abschalten, denn das schadet nicht. Wäre aber auch nicht überrascht, wenn es nicht hilft: ifconfig re0 -rxcsum -txcsum

Wenn es die NIC ist, und das wissen wir leider noch immer nicht, wäre mein Tipp nach wie vor, dass sich deren Firmware aus irgendwelchen Gründen so weit zersäbelt, das nur ein Kaltstart mit kompletter Hardware-Reinitialisierung hilft. Ich würde mal sowas im screen / tmux probieren: while : ; do date >> counter.txt ; sleep 10 ; done Dann nach dem Reset schauen, ob er durch den den Reset krepiert ist oder weit davor. War es erst durch den Reset, ist es fast sicher die NIC. Ist es weit davor passiert, crasht die Box an etwas anderem.
 
Zurück
Oben