romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(cluster): pveelite - cauza confirmata, resetul adaptorului USB LAN

Browse Source 
Nodul nu s-a oprit niciodata. La verificarea de azi avea uptime 17h46m, cu boot
pornit la 27.08 ora 16:03:06 - a mers toata noaptea, fara retea. Jurnalul
continua cu 58.454 de linii dupa 17:26:44, ceea ce inchide definitiv discutia
alimentare vs retea.

Vinovatul, din jurnalul kernel: Realtek RTL8156B (0bda:8156, driver r8152) pe
usb 2-3. La 16:01:45 si la 17:26:41 adaptorul s-a resetat si a fost re-enumerat.
Kernelul sterge interfata si o recreeaza - dar nimeni nu o readauga in vmbr0 si
nu o ridica, pentru ca nu exista regula de hotplug. Din acel moment masina merge
perfect si e invizibila in retea.

Partea care merita retinuta e de ce la 16:01 si-a revenit si la 17:26 nu. La
16:01 LRM-ul HA era activ, deci watchdog-ul era armat: pierderea retelei a dus la
pierderea quorumului, watchdog-mux a expirat la 16:02:39 si a resetat masina la
16:02:44 - repornire care a readus reteaua din intamplare, pentru ca la boot
interfetele se ridica prin auto. La 17:26 fence-ul mutase deja vm:109 pe pvemini,
LRM-ul era idle, watchdog-ul nearmat. Nimic nu a mai repornit masina. Singurul
lucru care "repara" defectul asta era un efect secundar, nu un mecanism proiectat
- pe un nod fara servicii HA, aceeasi defectiune devine permanenta si tacuta.

Reparat cu ifreload -a de la consola, la 09:49. Restul verificarii e curat: ZFS
ONLINE fara erori, cluster 3/3, SMART fara FAILED, replicarea se reia singura.

Reparatia de fond intra in Tier 1: eno1 exista si e functional, doar ca nu are
cablu (Link detected: no). Adaptorul USB e cauza a doua incidente pe nodul asta.
Am scris si ordinea operatiilor, pentru ca inversata te lasa fara retea cu drum
pana la nod.

Prima rulare reala a scriptului a scos la iveala trei defecte ale lui, toate
reparate aici:

- tiparele de semnatura hardware prindeau linii normale de boot ("Registered
  thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0") si produceau
  un verdict de defect hardware care contrazicea concluzia corecta din acelasi
  bilant. Strans tiparele si filtrat prin -p warning; verificat pe nod: 0
  potriviri.
- LRM idle era raportat ca "stare neclara". E starea normala a unui nod fara
  servicii HA - iar scriptul spune acum explicit ca idle inseamna watchdog
  nearmat, adica exact motivul pentru care caderea de la 17:26 nu s-a auto-reparat.
- Tailscale era raportat [ok] desi e delogat: systemctl is-active zice active, dar
  tailscale status zice "Logged out". De aici si cele 27 de zile de offline.

Consemnat si raspunsul la intrebarea cu magic packet, cu MAC-urile ambelor
interfete, ca sa nu se reia: WoL nu ar fi ajutat oricum, masina nu era oprita.
Dupa mutarea pe eno1 devine insa realmente utilizabil.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
This commit is contained in:
Marius
2026-08-28 09:55:10 +03:00
parent c67e7d8361
commit 5e31d975df
4 changed files with 169 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
proxmox/README.md
View File

@@ -13,7 +13,7 @@ proxmox/
│ │ ├── 2026-04-20-cluster-outage.md # Cascadă OOM pveelite + USB LAN watchdog
│ │ ├── 2026-04-30-pvemini-backup-ssd-hang.md # Kingston SSD hang → emergency mode
│ │ ├── 2026-07-31-lxc110-dns-tailscale-oom.md # DNS mort (Tailscale logout) + zram pe pve1
│ │ └── 2026-08-27-pveelite-down.md # DESCHIS — pveelite mort, suspiciune alimentare/hardware
│ │ └── 2026-08-27-pveelite-down.md # Reset adaptor USB LAN → pveelite fără rețea 16h
│ └── ups/ # Sistem UPS pentru cluster
│ ├── README.md
│ ├── docs/

2
proxmox/cluster/README.md
View File

@@ -870,7 +870,7 @@ swapon -a
- **2026-04-20 Cluster Outage:** `incidents/2026-04-20-cluster-outage.md` — post-mortem complet + plan prevenție
- **2026-04-30 pvemini backup SSD hang:** `incidents/2026-04-30-pvemini-backup-ssd-hang.md` — Kingston thermal hang → emergency mode
- **2026-07-31 LXC 110 DNS + OOM:** `incidents/2026-07-31-lxc110-dns-tailscale-oom.md` — logout Tailscale → DNS mort; zram instalat pe pve1
- **2026-08-27 pveelite down:** `incidents/2026-08-27-pveelite-down.md` — **DESCHIS** — nodul dispare la 16:01, revine, apoi cade definitiv la 17:26. Două ipoteze hardware: alimentare sau adaptorul USB de rețea. Verificare la revenire: `scripts/verifica-pveelite.ps1`
- **2026-08-27 pveelite fără rețea 16h:** `incidents/2026-08-27-pveelite-down.md` — resetul adaptorului USB LAN scoate interfața din `vmbr0` și nu o mai readaugă nimeni; mașina merge, dar e invizibilă. Fix: `ifreload -a`. De fond: mutarea pe `eno1`. Verificare: `scripts/verifica-pveelite.ps1`
### LXC Containers
- **LXC 108 - Oracle Database:** `../lxc108-oracle/README.md`

180
proxmox/cluster/incidents/2026-08-27-pveelite-down.md
View File

@@ -1,10 +1,12 @@
# Incident 2026-08-27 — pveelite cade definitiv la 4 ore după repornirea planificată a clusterului
# Incident 2026-08-27 — pveelite dispare din rețea 16 ore, cu mașina pornită (reset adaptor USB LAN)
**Severity:** Medium (zero impact pe producție — nodul nu găzduia niciun serviciu viu —
dar clusterul rămâne pe **2 voturi din 3**, fără marjă de quorum, și replicarea către
pveelite e oprită)
**Detected:** 2026-08-27 17:31 EEST (alertă automată `pveelite-down-alert.sh` → email)
**Status:** **DESCHIS** — nodul e inaccesibil, necesită intervenție fizică
**Resolved:** 2026-08-28 09:49 EEST (`ifreload -a` de la consola fizică)
**Status:** **REZOLVAT** — cauză confirmată din jurnal. Rămâne o acțiune de fond:
mutarea rețelei de pe adaptorul USB pe `eno1`
**Author:** Claude Code (mmarius28@gmail.com)
---
@@ -51,7 +53,64 @@ sau cedarea adaptorului USB de rețea. Ce se poate afirma acum:
- **Tiparul e de hardware:** reset spontan la 16:01, apoi moarte definitivă 85 de minute
mai târziu, pe o mașină idle. Semnătură clasică de PSU / RAM / termic.
### Ipoteza alternativă, care trebuie exclusă prima: adaptorul USB de rețea
### ROOT CAUSE CONFIRMAT (2026-08-28, din jurnalul nodului)
Nodul **nu s-a oprit niciodată**. La verificarea din 28.08 ora 09:49, `uptime` arăta
**17 ore și 46 de minute**, cu boot-ul pornit la **2026-08-27 16:03:06** — a mers
neîntrerupt toată noaptea, fără rețea. Lista de boot-uri confirmă:
```
-1 Thu 2026-08-27 13:20:28 -> Thu 2026-08-27 16:02:44
0 Thu 2026-08-27 16:03:06 -> Fri 2026-08-28 09:49:22
```
**Vinovatul:** adaptorul USB de rețea — Realtek RTL8156B, `0bda:8156`, „USB 10/100/1G/2.5G
LAN", driver `r8152`, pe portul `usb 2-3` al controllerului `xhci_hcd 0000:00:14.0`.
**Ce s-a întâmplat la 16:01:45** — adaptorul s-a resetat și a fost re-enumerat:
```
xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
vmbr0: port 1(enx6c1ff71abe67) entered disabled state
r8152 2-3:1.0 enx6c1ff71abe67 (unregistering): left promiscuous mode
usb 2-3: new SuperSpeed USB device number 3 using xhci_hcd
r8152 2-3:1.0 enx6c1ff71abe67: renamed from eth0
```
Kernelul șterge interfața și o recreează. **Interfața nouă nu e readăugată automat în
`vmbr0` și nu e ridicată** — nu există regulă de hotplug. Din acel moment mașina merge
perfect, dar nu mai are rețea.
**De ce la 16:01 și-a revenit, iar la 17:26 nu.** La 16:01 nodul avea LRM-ul HA **activ**,
deci watchdog-ul era armat. Pierderea rețelei a dus la pierderea quorumului, iar watchdog-ul
a resetat mașina — repornire care a readus rețeaua *din întâmplare*, pentru că la boot
interfețele se ridică prin `auto`:
```
16:02:08 pmxcfs: node lost quorum
16:02:08 pve-ha-crm: lost lock 'ha_manager_lock' -> status change master => lost_manager_lock
16:02:09 pve-ha-lrm: lost lock 'ha_agent_pveelite_lock' -> status change active => lost_agent_lock
16:02:39 watchdog-mux: client watchdog expired - disable watchdog updates
16:02:44 (ultima linie din boot-ul -1 — resetul hardware)
```
La **17:26:41** s-a produs exact același reset USB. De data asta însă fence-ul mutase deja
`vm:109` pe pvemini, LRM-ul era **idle**, deci **watchdog-ul nu mai era armat**. Nimic nu a
mai repornit mașina, și a rămas pornită și fără rețea 16 ore.
> **Concluzia neplăcută:** singurul lucru care „repara" defectul ăsta era watchdog-ul HA,
> adică un efect secundar, nu un mecanism proiectat. Pe un nod fără servicii HA, aceeași
> defecțiune devine permanentă și tăcută.
**Remediul aplicat:** `ifreload -a` de la consola fizică, la 09:49. Interfața și puntea au
revenit imediat (`vmbr0 UP`, `enx6c1ff71abe67 UP,LOWER_UP`), nodul a reintrat în cluster.
**Nu a fost alimentarea.** Nicio semnătură de eroare hardware în jurnal — zero potriviri
pentru MCE, panic, temperatură peste prag, EDAC sau erori de I/O.
---
### Ipoteza alternativă, formulată înainte de confirmare
**pveelite are placă de rețea pe USB**, iar deconectarea ei e modul de defectare deja
documentat al acestui nod: incidentul [2026-04-20](2026-04-20-cluster-outage.md) a pornit
@@ -117,7 +176,7 @@ Dacă da, mașina a mers mai departe și a căzut doar rețeaua.
---
## Starea la momentul investigației (21:22)
## Starea la momentul investigației (27.08, ora 21:22 — înainte de a se cunoaște cauza)
### Cluster
@@ -186,30 +245,35 @@ Merită consemnat, pentru că sunt exact lucrurile reparate după aprilie:
---
## Ce urmează — verificare la repornirea nodului
## Verificarea de la revenire — rezultate (2026-08-28 09:49)
Nodul se pornește fizic. Imediat după ce revine, se rulează
[`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin:
Rulat [`verifica-pveelite.ps1`](../scripts/verifica-pveelite.ps1) din stația de admin:
```powershell
.\proxmox\cluster\scripts\verifica-pveelite.ps1
```
| Verificare | Rezultat |
|---|---|
| Cauza căderii | **Cădere de rețea, nu de alimentare** — jurnalul continuă cu 58.454 de linii după 17:26:44 |
| Adaptor USB LAN | **Reseturi confirmate** la 16:01:45 și 17:26:41, cu re-enumerare `usb 2-3` |
| Semnături hardware | **Zero** — fără MCE, panic, temperatură peste prag, EDAC, erori de I/O |
| ZFS | `ONLINE`, fără erori de date, fără resilver |
| Cluster | **3 din 3 voturi**, marja de quorum refăcută |
| Replicare | se reia singură — `109-1 SYNCING`, restul `pending` |
| HA | LRM `idle` — normal, nodul nu are servicii asignate |
| SMART | fără `FAILED` pe discuri |
| Tailscale | serviciu pornit, dar **DELOGAT** — vezi Tier 1 |
Scriptul acoperă, în ordine:
### Trei defecte ale scriptului, găsite la prima rulare reală și reparate
1. **S-a oprit mașina, sau doar a dispărut din rețea?** Testul decisiv: există intrări în
jurnal după 17:26:44? Dacă da → a mers mai departe, a căzut rețeaua (adaptorul USB), iar
reparația e la dongle/cablu/switch. Dacă nu → mașina chiar s-a oprit, și atunci contează
dacă jurnalul e tăcut înainte (MCE, termic, panic, EDAC). **Tăcere = alimentare/hardware,
nu software** — și atunci nodul nu mai e de încredere ca țintă de failover.
2. **Integritatea ZFS** — `zpool status -v` după două opriri necurate; se așteaptă
eventual un resilver automat, ca în aprilie.
3. **Revenirea în cluster** — quorum 3/3, `pvecm status`, `/etc/pve/.members`.
4. **Repornirea replicării** — `pvesr status`, FailCount înapoi la 0, toate cele 9 job-uri
recuperate. Nu necesită intervenție manuală; se reiau singure.
5. **HA** — LRM pveelite `active`, nu `dead`.
6. **SMART pe discuri** — temperaturi și erori, dat fiind precedentul Kingston.
7. **Tailscale** — repornit și `Online`, ca să existe acces out-of-band data viitoare.
1. **Fals pozitiv la semnăturile hardware.** Tiparele inițiale (`thermal`, `nmi`, `edac`,
`BUG:`) prindeau linii normale de boot — „Registered thermal governor", „NMI watchdog:
Enabled", „EDAC MC: Ver: 3.0.0" — și produceau un verdict de defect hardware care
**contrazicea concluzia corectă din același bilanț**. Tiparele au fost strânse și
filtrate prin `-p warning`; verificat pe nod: 0 potriviri.
2. **LRM `idle` raportat ca „stare neclară".** `idle` e starea normală a unui nod fără
servicii HA. Acum e tratată ca atare — și, mai important, scriptul spune explicit că un
LRM idle înseamnă **watchdog nearmat**, adică fix motivul pentru care căderea de la 17:26
nu s-a auto-reparat.
3. **Tailscale raportat `[ok]` deși era delogat.** `systemctl is-active` întorcea `active`,
dar `tailscale status` spunea `Logged out`. Verificarea se uită acum la starea reală.
---
@@ -224,40 +288,58 @@ fizică.
ssh root@10.0.20.202 "systemctl enable --now tailscaled && tailscale up && tailscale status"
```
**2. Verdictul hardware, scris explicit.**
Dacă `journalctl -b -1` nu conține nimic înainte de 17:26 (tăcere completă, ca la pvemini pe
2026-04-20), atunci **cauza e hardware și nodul trebuie tratat ca nesigur** până la
înlocuirea sursei / testare RAM. Nu se lasă concluzia „a mers, deci e bine".
**2. Mută rețeaua de pe adaptorul USB pe `eno1` — reparația de fond.**
`eno1` **există și e funcțional**, doar că nu are cablu: `Link detected: no`, driver
încărcat, `Supports Wake-on: pumbg`. Adaptorul USB e cauza a **două** incidente pe acest nod
(2026-04-20 și cel de față) și rămâne un punct unic de cedare pe magistrala USB.
**3. Notează adresa MAC a lui pveelite — acum nu o mai are nimeni.**
În timpul incidentului s-a pus întrebarea dacă nodul poate fi trezit cu un magic packet
(Wake-on-LAN). **Nu s-a putut nici măcar încerca:** intrarea ARP expirase peste tot —
`ip neigh` pe pvemini (`INCOMPLETE`) și pe pve1 (`FAILED`), tabela ARP a stației de admin,
LXC-urile de pe LAN. Nodurile au IP static, deci nu există lease DHCP, iar MAC-ul nu e
consemnat în documentație. Singurele surse rămase: tabela ARP/DHCP a routerului 10.0.20.1
sau citirea fizică de pe nod.
Separat de asta, **WoL are șanse mici pe acest nod**: placa de rețea e pe USB, iar un
adaptor USB rămâne nealimentat în stare soft-off, deci nu poate asculta după magic packet.
De verificat la repornire, împreună cu MAC-ul:
Ordinea contează, altfel rămâi din nou fără rețea, cu drum până la nod:
```bash
ssh root@10.0.20.202 "ip -br link; ethtool <iface> | grep -iE 'Wake-on|Supports Wake'"
# 1. Mută fizic cablul LAN din dongle-ul USB in portul eno1 de pe placa de baza.
# 2. De la CONSOLA fizica (nu prin SSH — reteaua pica in timpul operatiei):
sed -i 's/bridge-ports enx6c1ff71abe67/bridge-ports eno1/' /etc/network/interfaces
ifreload -a
ip -br link # eno1 trebuie sa fie UP, vmbr0 UP
```
Dacă apare `Supports Wake-on: g` și se activează și în BIOS, WoL devine posibil. Dacă nu,
concluzia se scrie explicit aici, ca să nu se reia discuția la următorul incident.
Dongle-ul USB rămâne ca rezervă, scos din `vmbr0`.
**4. Textul alertei — scos exportul NFS inexistent.**
**3. Regulă de hotplug, dacă adaptorul USB rămâne în uz.**
Cauza reală nu e resetul USB în sine — e faptul că interfața recreată **nu e readăugată în
punte**. `auto enx...` în `/etc/network/interfaces` ridică interfața doar la boot;
`allow-hotplug` o ridică și la re-enumerare. Fără asta, orice reset USB scoate nodul din
rețea definitiv.
**4. Adresele MAC — consemnate acum, ca să nu se mai piardă.**
| Interfață | MAC | Wake-on-LAN |
|---|---|---|
| `eno1` (placă de bază) | `84:69:93:57:b2:ea` | `Supports: pumbg`, activ `g` |
| `enx6c1ff71abe67` (USB Realtek RTL8156B) | `6c:1f:f7:1a:be:67` | `Supports: pumbg`, activ `g` |
În timpul incidentului s-a pus întrebarea dacă nodul poate fi trezit cu un magic packet.
**Nu s-a putut nici măcar încerca:** intrarea ARP expirase peste tot — `ip neigh` pe pvemini
(`INCOMPLETE`) și pe pve1 (`FAILED`), tabela stației de admin, LXC-urile de pe LAN. Nodurile
au IP static, deci nu există lease DHCP, iar MAC-ul nu era consemnat nicăieri.
Concluzia, scrisă explicit ca să nu se reia discuția: **WoL nu ar fi ajutat oricum** — mașina
nu era oprită, ci pornită și fără rețea. Un magic packet nu are ce trezi. După mutarea pe
`eno1`, WoL devine însă realmente utilizabil, pentru că e placă integrată, alimentată în
soft-off — spre deosebire de un dongle USB.
**5. Textul alertei — scos exportul NFS inexistent.**
`/opt/scripts/pveelite-down-alert.sh` menționează `10.0.20.202:/mnt/pve/oracle-backups`, care
nu mai e în `storage.cfg`. Cine citește alerta la 3 noaptea o ia pe o pistă falsă.
### 🟡 Tier 2 — de decis după verdictul hardware
### 🟡 Tier 2
**5. Ce se întâmplă cu marja de quorum.**
Cât timp pveelite e nesigur, clusterul funcționează pe 2 din 3 voturi. Nu se umblă la
`expected votes` cât timp e quorate — dar dacă nodul urmează să stea oprit zile întregi,
merită decis conștient dacă rămâne în cluster sau se scoate temporar.
**6. Detecția tăcerii — nodul a stat 16 ore căzut fără să afle nimeni.**
Alerta a funcționat corect la 17:31, dar apoi incidentul a rămas nesupravegheat peste noapte.
Mai grav: pe un nod **fără servicii HA**, watchdog-ul nu e armat, deci nu există niciun
mecanism care să repare sau măcar să semnaleze o cădere de rețea. Nodul rămâne pornit,
sănătos și invizibil. Merită o alertă de repetiție (nu doar una la început de incident) sau
un al doilea inel corosync pe `eno1`, care ar fi ținut nodul în cluster peste căderea USB.
**6. `local-zfs` pe pvemini la 92 %.**
**7. `local-zfs` pe pvemini la 92 %.**
Separat de incident, dar pe același nod pe care stă acum toată producția.
---

42
proxmox/cluster/scripts/verifica-pveelite.ps1
View File

@@ -67,8 +67,18 @@ $IncidentStart = '2026-08-27 13:20' # boot-ul de dupa oprirea planificata
# Tipare de eroare hardware in jurnalul kernel. Daca NICIUNUL nu apare, verdictul
# inclina spre alimentare (masina nu apuca sa scrie nimic inainte sa dispara).
$TipareHw = 'mce|machine check|hardware error|thermal|temperature above|critical temp|' +
'nmi|kernel panic|oops|BUG:|edac|pcieport.*error|ATA bus error|I/O error'
#
# Tiparele sunt deliberat STRANSE. Prima versiune cauta 'thermal', 'nmi', 'edac',
# 'BUG:' si a raportat fals pozitiv la rularea din 28.08: liniile normale de boot
# ("Registered thermal governor", "NMI watchdog: Enabled", "EDAC MC: Ver: 3.0.0",
# "DPC: error containment capabilities") au declansat un verdict de defect hardware
# care contrazicea concluzia corecta. Un fals pozitiv aici nu e zgomot inofensiv -
# trimite pe pista gresita exact cand trebuie luata o decizie.
$TipareHw = 'Machine Check|mce: |Hardware Error|Uncorrected error|' +
'temperature above threshold|critical temperature|' +
'Kernel panic|Oops: |watchdog: BUG: soft lockup|' +
'EDAC.*(CE|UE) .*error|AER: .*error|Buffer I/O error|' +
'blk_update_request.*I/O error|ATA bus error'
$ReplJobs = 9 # 9 job-uri de replicare au pveelite ca tinta
@@ -241,14 +251,16 @@ if ($usbEv) {
# Cautarea tintita de semnaturi hardware, peste toate boot-urile de ieri.
Write-Host ""
Write-Info "--- semnaturi hardware in jurnal (MCE / termic / panic / EDAC) ---"
# -p warning taie zgomotul de boot inainte de a ajunge la grep: mesajele de
# inregistrare a guvernatorilor termici, EDAC si NMI sunt de nivel info.
$hw = Invoke-Node -Node pveelite -Command `
"journalctl --since '$IncidentStart' --no-pager | grep -iE '$TipareHw' | tail -25"
"journalctl --since '$IncidentStart' -p warning --no-pager | grep -E '$TipareHw' | tail -25"
$verdictHw = $false
if ($hw) {
Write-Bad "GASIT - nodul a lasat urme de eroare hardware:"
$hw | ForEach-Object { Write-Host " $_" -ForegroundColor Red }
Add-Rezultat 'Cauza caderii' 'bad' 'semnaturi hardware in jurnal - vezi liniile de mai sus'
Add-Rezultat 'Semnaturi hardware' 'bad' 'erori hardware in jurnal - vezi liniile de mai sus'
$verdictHw = $true
} else {
Write-Info "niciun MCE, eroare termica, panic sau EDAC in jurnal"
@@ -354,6 +366,16 @@ $ha | ForEach-Object { Write-Info $_ }
if ($ha -match 'lrm pveelite \(active') {
Write-Ok "LRM pveelite activ"
Add-Rezultat 'HA' 'ok' 'LRM activ'
} elseif ($ha -match 'lrm pveelite \(idle') {
# 'idle' e starea normala pentru un nod fara servicii HA asignate - si e
# exact cazul lui pveelite dupa ce fence-ul a mutat vm:109 pe pvemini.
# ATENTIE: cu LRM idle, watchdog-ul NU e armat. La 16:01 watchdog-ul a
# repornit nodul si i-a readus reteaua; la 17:26, fara el, nodul a ramas
# pornit si fara retea pana dimineata.
Write-Ok "LRM pveelite idle - normal, nodul nu are servicii HA asignate"
Write-Info "Consecinta: watchdog-ul nu e armat, deci o cadere de retea nu se"
Write-Info "mai auto-repara prin reboot, cum s-a intamplat la 16:01."
Add-Rezultat 'HA' 'ok' 'LRM idle (fara servicii asignate) - watchdog nearmat'
} elseif ($ha -match 'lrm pveelite.*old timestamp') {
Write-Warn "LRM pveelite inca 'dead' - poate dura un minut dupa boot; reverifica"
Add-Rezultat 'HA' 'warn' "LRM inca 'old timestamp'"
@@ -406,8 +428,16 @@ Write-Info "viitoare a nodului cere din nou deplasare fizica."
$ts = Invoke-Node -Node pveelite -Command 'systemctl is-active tailscaled 2>/dev/null; tailscale status 2>&1 | head -3'
$ts | ForEach-Object { Write-Info $_ }
if ($ts -match '^active') {
Write-Ok "tailscaled activ"
if ($ts -match 'Logged out|Stopped') {
# Capcana: serviciul poate fi 'active' si totusi inutilizabil. Exact asa arata
# pveelite la 28.08 - tailscaled pornit, dar delogat, ceea ce explica cele 27
# de zile de "offline". A verifica doar systemctl is-active da un fals OK.
Write-Bad "tailscaled ruleaza, dar e DELOGAT - nu exista acces out-of-band"
Write-Info "Reautentificare (cere deschiderea link-ului afisat intr-un browser):"
Write-Info " ssh root@$($NodeIp.pveelite) 'tailscale up'"
Add-Rezultat 'Tailscale' 'bad' 'delogat - fara acces out-of-band'
} elseif ($ts -match '^active') {
Write-Ok "tailscaled activ si autentificat"
Add-Rezultat 'Tailscale' 'ok' 'activ'
} else {
Write-Warn "tailscaled NU e activ - reactiveaza-l acum:"