ROMFASTSQL/docs/incident-2026-08-10-server36-standby.md

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

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:

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

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

# 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:

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