# Incident 10 august 2026 — server 10.0.20.36 „blocat" 20 de minute

**Concluzie:** serverul nu s-a blocat și nu a crăpat. A intrat în **standby (S3)** la 12:02:20 în
urma unei acțiuni de power de la consolă și a stat adormit până la 12:22:04. Oracle nu a fost oprit,
doar suspendat în RAM.

## Server

`ROA-CARAPETRU2` / 10.0.20.36 — Windows 11 Pro 26200, Oracle 19c SE2, instanța `ROA`.
Acces: `ssh -p 22122 Administrator@10.0.20.36`.

## Cronologia (ora locală, GTB +03:00)

| Ora | Sursa | Eveniment |
|---|---|---|
| 11:45:36 | System `566` Kernel-Power | ultimul input fizic la consolă înainte de incident (`InputHid`) |
| ~11:50 | — | monitorul se stinge (`VIDEOIDLE` AC = 300 s = 5 min) |
| 12:00:00 | System `6013` | uptime 2.285.772 s = 26 zile 11 h, neîntrerupt din 15 iulie |
| 12:00:02–12:00:18 | listener.log | 8 conexiuni la ROA dintr-un program din `C:\Users\Administrator\Downloads\` |
| 12:01:04 | System `7040` | BITS trece demand → auto |
| 12:01:26 | listener.log | **ultima conexiune client reală**: `ROACONT.exe` de pe `RAMONA` |
| 12:01:58 | listener.log | ultimul poll local |
| 12:02:14 | System `1074` User32 | **Explorer.EXE** inițiază power off, pe seama `ROA-CARAPETRU2\Administrator`, „Other (Unplanned)" |
| 12:02:14 | Security `4624`×3 | winlogon creează sesiunea 2 (UMFD-2, DWM-2) |
| 12:02:19 | Security `4647` | „User initiated logoff" pentru Administrator (SID …-500) |
| 12:02:19 | System `100` winsrvext | `rundll32.exe` (5016 ms) și `ATI…\CCC.exe` (5078 ms) întârzie oprirea |
| 12:02:20 | System `1074` | winlogon.exe continuă power off |
| 12:02:20 | System `566` | tranziție sesiune, `Reason **InputHid**` — input fizic exact în acel moment |
| 12:02:20 | System `187` Kernel-Power | proces user-mode apelează `SetSuspendState`/`SetSystemPowerState` |
| 12:02:20 | System `42` Kernel-Power | **„The system is entering sleep. Sleep Reason: Application API"** |
| 12:02:20 | RDP LSM `23/24/39/40` | sesiunea 1 delogată/deconectată, `Source Network Address: LOCAL` |
| **12:02–12:22** | listener.log | **gaură totală — zero activitate** |
| 12:22:04 | Power-Troubleshooter | trezire. Sleep 09:02:20 UTC → Wake 09:22:04 UTC. `Wake Source: Unknown` |
| 12:22:03 | Kernel-General `1` | ceasul sare înapoi la timpul real (delta 1.180.963 ms ≈ 19 min 41 s de somn) |
| 12:22:03 | listener.log | `service_update * roa * 0` — listenerul revine |
| 12:22:48+ | listener.log | clienții reconectează: ELENA-I5, RAMONA, ROXANA, DESKTOP-DJ8G35U, STELUTA-PC, LG17 |
| 12:31:25 | RDP LSM `21` | logon consolă Administrator (sesiunea 2) |

## Dovezi că NU a fost blocaj, crash sau oprire

- Zero evenimente `41` (Kernel-Power / oprire neașteptată), `6008` (unexpected shutdown), `1001`
  (BugCheck/BSOD) — nici în ziua incidentului, nici în ultimele 10 zile.
- Zero evenimente Error/Critical în `System` (3 zile) și `Application` (2 zile).
- `BootId: 30` neschimbat pe toată durata → **nu a existat repornire**.
- `LastBootUpTime` = 15 iulie 2026 01:03:48; `oracle.exe` și `tnslsnr.exe` au `StartTime`
  15 iulie 01:02:56 → procesele Oracle nu s-au oprit niciodată.
- **Listener.log demonstrează că baza servea normal până în secunda adormirii**: clienți reali la
  11:45, 11:47–11:53 (SILVIA-ENVY), 11:50 (JENI), 12:01:26 (RAMONA). Distribuția pe ore în ziua
  respectivă este continuă (09→56, 10→63, 11→47, 12→56 conexiuni). Singura discontinuitate din zi
  este fereastra 12:01:58 → 12:22:03.

Cu alte cuvinte: **până la 12:02 nimic nu era în neregulă**. Indisponibilitatea de 20 de minute a
fost provocată chiar de acțiunea de la 12:02, nu de o defecțiune anterioară.

## Cauza

Standby-ul nu a venit din inactivitate — `STANDBYIDLE` pe AC = 0 (Never), `HIBERNATEIDLE` AC = 0, iar
`Sleep Reason` este `Application API`, nu `Idle`. A fost o **comandă explicită de power dată de la
consolă**, care s-a executat ca *Sleep* în loc de *Shut down*:

- `UIBUTTON_ACTION` („Start menu power button") are valoarea efectivă **0 = Sleep**.
- Nu există override în schema activă (`…\PowerSchemes\381b4222…\4f971e89…`) pentru acțiunea
  butonului fizic de power (`PBUTTONACTION`) sau sleep (`SBUTTONACTION`) — ambele au `Attributes=1`,
  adică sunt **ascunse din interfața Windows**, deci nici nu pot fi verificate/schimbate din
  Control Panel fără intervenție în registry.
- `Explorer.EXE` este exact procesul care tratează butonul de power din meniul Start, iar
  `566 Reason InputHid` la 12:02:20 confirmă input fizic în acel moment.

**Ce nu se poate proba din loguri:** care buton anume a fost apăsat (meniul Start vs. butonul fizic).
Auditarea creării de procese (`Process Creation`) este dezactivată, deci nu există `4688` care să
arate ce a lansat `rundll32.exe`. Mecanismul și rezultatul sunt însă certe.

Trezirea de la 12:22:04 (`Wake Source: Unknown`) corespunde apăsării butonului de power — de aceea
calculatorul „s-a aprins", ceea ce a fost interpretat drept dovadă că era în standby. Era, dar
ajunsese acolo în urma acțiunii de la 12:02.

## Probleme reale descoperite pe parcurs

1. **Serverul poate intra în S3.** Pe o mașină de producție cu Oracle, stările de somn trebuie
   eliminate complet, nu doar setate pe „Never" — atâta timp cât S3 e disponibil, orice apăsare
   greșită oprește baza pentru toți clienții.
2. **Comunicația ViewPower ↔ UPS este moartă.** `C:\ViewPower\log\log4j.log` conține continuu
   `QPI return(NAK`, iar baza de date proprie (`C:\ViewPower\datas\log5xx.dat`) nu mai fusese scrisă
   din 9 august 23:10. Configurația (`C:\ViewPower\config\ups.properties`) are
   `Shutdownconfigure.batModeShutdown=true` cu `batModeShutdownTime=30` — adică *ar trebui* să oprească
   serverul controlat după 30 min pe baterie. Cu comunicația căzută, la o pană reală de curent
   **nu va face nimic**.

   Hardware-ul e însă în regulă: Windows vede nativ `HID UPS Battery`
   (`HID\VID_0665&PID_5161&MI_01` — Cypress/Voltronic), `Win32_Battery` raportează Status OK,
   100% încărcare, ~70 min autonomie. **Repornirea serviciului `upsMonitor` nu rezolvă**: după
   restart au venit 2 răspunsuri valide (`QPI returnQPI` la 22:24:10 și 22:24:12), apoi s-a întors
   la `NAK` (197 NAK / 2 valide în ultimele 200 de linii). Tiparul indică o dispută pe același
   device USB HID între driverul nativ Windows și ViewPower.
3. **Fast Startup este activ** (`HiberbootEnabled=1`) pe un server Oracle de producție. De aceea
   uptime-ul se acumulează de 26 de zile — un „shutdown" normal nu mai face repornire curată a
   kernelului.
4. **Healthcheck greșit configurat — și inutil.** Sursa: `roa2web`, fișierul
   `C:\inetpub\wwwroot\roa2web\backend\shared\ssh_tunnel_manager.py`:
   - linia **68**: `self.check_interval: int = 30`
   - linia **186**: `await self._check_port("127.0.0.1", port)`
   - liniile **218-230**: `_check_port` face `asyncio.open_connection` și închide imediat, fără
     handshake TNS → listenerul îl loghează ca `TNS-12537`.

   Portul vine din `C:\inetpub\wwwroot\roa2web\backend\ssh-tunnels.json`, unde tunelul „vending"
   are `"local_port": 1521`. **Dar 1521 e portul listenerului de producție de pe acest server**,
   iar `.env` declară vending-ul pe `localhost:**1522**`. Consecințe:
   - tunelul SSH nu poate lega portul 1521, e ocupat de Oracle local;
   - verificarea reușește întotdeauna, pentru că lovește listenerul local — **monitorul raportează
     tunelul „sănătos" indiferent de realitate** și nu declanșează niciodată repornirea;
   - nu rulează niciun proces `ssh.exe`, deci tunelul vending e oricum căzut de la ultima pornire.
5. **ORACLE_HOME e sub `C:\Users\Administrator\Downloads\WINDOWS.X64_193000_db_home\`.**
   Listenerul de producție rulează din folderul Downloads. Funcționează, dar e o amplasare fragilă.

## Remediere APLICATĂ pe 10 august 2026, seara

```powershell
powercfg /hibernate off                                                   # sleep+hibernate+Fast Startup
powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS PBUTTONACTION 3      # buton fizic -> Shut down
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS PBUTTONACTION 3
powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS UIBUTTON_ACTION 2    # meniu Start -> Shut down
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS UIBUTTON_ACTION 2
powercfg /setacvalueindex SCHEME_CURRENT SUB_BUTTONS SBUTTONACTION 0      # buton sleep -> Do nothing
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BUTTONS SBUTTONACTION 0
powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP abfc2519-3608-4c2a-94ea-171b0ed546ab 0   # ALLOWSTANDBY
powercfg /setdcvalueindex SCHEME_CURRENT SUB_SLEEP abfc2519-3608-4c2a-94ea-171b0ed546ab 0
powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP STANDBYIDLE 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_SLEEP STANDBYIDLE 0          # era 600 s pe DC!
powercfg /setacvalueindex SCHEME_CURRENT SUB_SLEEP HIBERNATEIDLE 0
powercfg /setdcvalueindex SCHEME_CURRENT SUB_SLEEP HIBERNATEIDLE 0
powercfg /setactive SCHEME_CURRENT
```

Setările de buton erau ascunse din UI (`Attributes=1`); au fost făcute vizibile punând
`Attributes=2` sub
`HKLM\SYSTEM\CurrentControlSet\Control\Power\PowerSettings\4f971e89-…\{7648efa3-…,96996bc0-…}`.

**Corecție obligatorie făcută imediat după:** `Critical battery action` era `2 = Hibernate`, iar
hibernarea tocmai fusese dezactivată — la o pană reală Windows ar fi încercat să hiberneze și ar fi
eșuat. Corectat, împreună cu pragurile, care erau prea joase pentru un shutdown curat de Oracle:

```powershell
powercfg /setacvalueindex SCHEME_CURRENT SUB_BATTERY BATACTIONCRIT 3   # 3 = Shut down (era 2 = Hibernate)
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BATTERY BATACTIONCRIT 3
powercfg /setacvalueindex SCHEME_CURRENT SUB_BATTERY BATLEVELCRIT 20   # era 5%
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BATTERY BATLEVELCRIT 20
powercfg /setacvalueindex SCHEME_CURRENT SUB_BATTERY BATLEVELLOW  40   # era 10%
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BATTERY BATLEVELLOW  40
powercfg /setacvalueindex SCHEME_CURRENT SUB_BATTERY f3c5027d-cd16-4930-aa6b-90db844a8f00 25  # reserve, era 7%
powercfg /setdcvalueindex SCHEME_CURRENT SUB_BATTERY f3c5027d-cd16-4930-aa6b-90db844a8f00 25
powercfg /setactive SCHEME_CURRENT
```

### Verificat după aplicare

`powercfg /a` nu mai listează **nicio** stare de somn disponibilă:
`Standby (S3)` → „The current power policy has disabled this standby state";
`Hibernate` → „Hibernation has not been enabled"; `Hybrid Sleep` și `Fast Startup` → indisponibile.
`C:\hiberfil.sys` a fost eliminat. Butoane: power = `0x3` (Shut down), sleep = `0x0` (Do nothing),
meniu Start = `0x2` (Shut down), pe AC și pe DC.

Oprirea Oracle la shutdown-ul Windows e configurată corect — `HKLM\SOFTWARE\ORACLE\KEY_OraDB19Home1`:
`ORA_ROA_SHUTDOWN=TRUE`, `ORA_ROA_SHUTDOWNTYPE=immediate`, `ORA_ROA_SHUTDOWN_TIMEOUT=90`,
`ORA_ROA_AUTOSTART=TRUE`. Deci la pană de curent, cu bateria sub 20%, Windows va face
`shutdown immediate` curat pe ROA.

**Protecția la pană de curent nu mai depinde de ViewPower** — Windows o face nativ, prin driverul
`HID UPS Battery` care funcționează corect.

## Aplicat în plus (decizii luate de utilizator)

### ViewPower — dezactivat

```powershell
Stop-Service upsMonitor -Force ; Set-Service upsMonitor -StartupType Disabled
Stop-Service upsTomcat  -Force ; Set-Service upsTomcat  -StartupType Disabled
```

Ambele `Stopped` / `Disabled`. Verificat că Windows vede în continuare UPS-ul după oprirea lor:
`Win32_Battery` → `HID UPS`, 100%, ~70 min autonomie, `Critical battery action = 0x3` (Shut down)
la `Critical battery level = 0x14` (20%). **Protecția la pană de curent este intactă.**

### Tunelul „vending" — port corectat, dar tunelul e defect din altă cauză

`C:\inetpub\wwwroot\roa2web\backend\ssh-tunnels.json` (backup: `…json.bak-20260810`):
`"local_port": 1521` → **`1522`**, ca să corespundă cu `.env` și să nu mai sondeze listenerul de
producție. Adăugat și `"ssh_hostkey": "SHA256:Vptuj1UUGA9eSk/utwyLvS5C1pzgpYyyUFwUd60S6Go"`
(cheia ECDSA a serverului, obținută cu `ssh-keyscan`), fiindcă scriptul rulează plink cu `-batch`
și fără `-hostkey` acesta abandona imediat.

**Tunelul tot nu pornește** — cauză reală, preexistentă (nu rula niciun `ssh.exe` de la boot-ul din
15 iulie):

```
plink -batch -P 22122 romfast@79.119.86.134
FATAL ERROR: Remote side sent disconnect message type 11 (by application):
"Client software or version not permitted."
```

Serverul vending respinge plink după banner-ul de versiune — acceptă doar clienți OpenSSH. Deci
**autentificarea cu parolă prin plink nu va funcționa niciodată acolo**, indiferent de config.
Calea cu cheie nu merge nici ea: `secrets\vending.ssh_key` nu există, iar `secrets\romfast.ssh_key`
nu e autorizată pe server:

```
ssh -i secrets\romfast.ssh_key -p 22122 romfast@79.119.86.134
romfast@79.119.86.134: Permission denied (publickey,password)
```

Conectivitatea TCP către `79.119.86.134:22122` funcționează, iar serverul anunță `publickey,password`.

### Tunelul „vending" — dezactivat, la cererea utilizatorului

În `ssh-tunnels.json` cheia `"ssh_host"` a fost redenumită `"ssh_host_disabled"`
(backup: `…json.bak-inainte-dezactivare`). `_load_config` (linia 106) păstrează doar intrările care
au `ssh_host`, deci lista rămâne goală, iar `start_monitoring` iese devreme (liniile 129-131) —
**bucla de monitorizare nu mai pornește deloc**, deci nici `_restart_tunnels` nu poate fi apelat.
Toate datele de conectare rămân în fișier, pentru reactivare ușoară: se redenumește cheia înapoi.

Backend-ul rulează ca serviciu Windows **`ROA2WEB-Backend`** (wrapper NSSM, pornire automată,
scriptul `scripts\start-backend-service.ps1`). Repornit cu `Restart-Service ROA2WEB-Backend -Force`
pe 10 august la 22:40:45, ca modificarea să fie citită.

**Verificat după repornire:**

```
GET http://127.0.0.1:8000/health  ->  HTTP 200
{"api":"healthy","modules":{"oracle":"connected","reports_cache":"initialized",
 "data_entry_db":"exists","telegram_bot":"running","ocr_worker":{"status":"running"},
 "ssh_tunnels":{"status":"not_configured","tunnels":{},"monitoring":false}}}
```

`monitoring: false` — monitorul e oprit. În 100 de secunde de observație: **0 sonde `TNS-12537`**
în `listener.log` (înainte: una la fiecare 30 s). Zgomotul din logul listenerului a încetat.

## Rămâne de făcut

**Doar dacă se dorește repunerea în funcțiune a tunelului vending.** Este căzut de dinainte de
incident (niciun `ssh.exe` de la boot-ul din 15 iulie), deci integrarea vending nu funcționa oricum:

1. Adăugat conținutul lui `secrets\romfast.ssh_key.pub` în `~/.ssh/authorized_keys` al utilizatorului
   `romfast` pe 79.119.86.134 — autentificarea cu parolă prin plink e blocată definitiv de server.
2. Copiat `romfast.ssh_key` ca `secrets\vending.ssh_key` (scriptul caută cheia după `id`-ul tunelului).
3. Redenumit `"ssh_host_disabled"` înapoi în `"ssh_host"` și repornit `ROA2WEB-Backend`.

## Decizii inițiale (istoric)

1. **ViewPower** — repornirea nu a rezolvat comunicația. Fiind redundant față de gestionarea nativă
   Windows (și declarând un rol de shutdown pe care nu-l poate îndeplini), recomandarea e să fie
   dezactivat: `Set-Service upsMonitor -StartupType Disabled; Stop-Service upsMonitor`. Alternativ,
   de reconfigurat protocolul UPS din interfața lui (Tomcat, port 15178). De reținut și că
   `emailReceivers.length() = 0` — nu are configurată nicio alertă pe email.
2. **Healthcheck-ul roa2web** — vezi mai jos. Orice variantă cere repornirea backend-ului roa2web
   (uvicorn, PID-uri 6980/6292/8464, pornit din `C:\inetpub\wwwroot\roa2web-venv`).

### Opțiuni pentru healthcheck

| Variantă | Ce se schimbă | Efect |
|---|---|---|
| **A. Dezactivare (recomandat)** | scoate `"ssh_host"` din intrarea „vending" din `ssh-tunnels.json`, sau șterge intrarea | linia 106 filtrează intrările fără `ssh_host` → monitorul nu mai sondează nimic. Zero zgomot. Corect, pentru că tunelul oricum nu rulează |
| **B. Corectare port** | `"local_port": 1521` → `1522` (ca în `.env`) | sonda se mută de pe listenerul de producție pe portul real al tunelului. **Atenție:** monitorul va raporta corect DOWN și, după 2 eșecuri, va încerca `_restart_tunnels()` la fiecare ≥60 s — buclă de repornire, dacă tunelul nu poate porni |
| **C. Rărire** | `ssh_tunnel_manager.py:68` `check_interval: int = 30` → `300` | de 10 ori mai puțin zgomot, dar problema de fond (sondează listenerul greșit, raportează fals „sănătos") rămâne |
| **D. Tăcere pe listener** | `LOGGING_LISTENER = OFF` în `listener.ora` | **nerecomandat** — pierzi exact logul care a rezolvat incidentul de azi |

## Comenzi utile pentru reinvestigare

```powershell
# Cronologia completa a unei zile din System log
Get-WinEvent -FilterHashtable @{LogName='System';StartTime=(Get-Date "AAAA-LL-ZZ 09:00:00")} |
  Sort-Object TimeCreated | Select-Object TimeCreated,Id,ProviderName,Message

# Evenimente de power/oprire
Get-WinEvent -FilterHashtable @{LogName='System';Id=41,42,107,187,1074,6005,6006,6008,6013,1001}

# Ferestre de indisponibilitate reala, din perspectiva clientilor
Select-String -Path "C:\Users\oracle\diag\tnslsnr\ROA-CARAPETRU2\listener\trace\listener.log" `
  -Pattern "^\d{2}-[A-Z]{3}-\d{4} (\d{2}):\d{2}:\d{2}.*establish"
```

Rularea comenzilor de la distanță se face cu `-EncodedCommand` (base64 UTF-16LE), altfel quoting-ul
prin `ssh` din Git Bash/PowerShell strică scripturile:

```powershell
$enc = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($script))
ssh -p 22122 Administrator@10.0.20.36 "powershell -NoProfile -EncodedCommand $enc"
```