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

depanare

Browse Source
This commit is contained in:
Marius Mutu
2026-09-16 23:37:56 +03:00
parent 6239681ac7
commit 69adfe4a61
1 changed files with 91 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
docs/depanare-server-update-roa.md
View File

@@ -177,3 +177,94 @@ Dupa kill, totul revine imediat - nu e nevoie de restart de sit sau de recycle d
De urmarit daca se repeta: de ce se agata linkul `DBL_ROMFAST2` spre 10.0.20.36 (timeout de retea
fara detectie - merita un `SQLNET.EXPIRE_TIME` / `outbound_connect_timeout` pe link-ul respectiv).
## Anatomia fallback-ului PACK_UTILS: de ce ORA-29024 nu inseamna certificat
Referinta: `SCRIPTURI_CLAR/2026/09/co_2026_09_16_02_COMUN_PACK_UTILS.sql`.
`URL2Clob` (linia 333) si `URL2Blob` (linia 284) lucreaza pe **acelasi** `tcURL` si au **doua**
ramuri de transport una dupa alta; nu exista un URL separat "fara SSL". URL-ul vine din
`optiuni.UPD_URL_APP` (vezi mai sus).
**Ramura 1 - curl extern.** Se intra doar daca `SERVER_INFO.POWERSHELLDOWNLOAD = '1'`
(`URL2Clob`:347, `URL2Blob`:298). `DownloadFileOS` (`URL2Clob`:353, `URL2Blob`:304) scrie un script
PowerShell cu `curl.exe -k -o "<dest>.part"` (linia 756), il ruleaza prin `sys.ExecuteScriptOS`
(linia 766) si asteapta prin polling pana la `SERVER_INFO.POWERSHELLTIMEOUT` secunde (implicit 60:
linia 696, bucla liniile 771-775) sa apara fisierul final; redenumirea din `.part` o face
`$LASTEXITCODE` (linia 758). Criteriul de succes e **doar existenta fisierului**
(liniile 772-773 si 777-778).
**Ramura 2 - HTTPURITYPE.** Se atinge cand `llDownloaded = FALSE` **sau** cand
`POWERSHELLDOWNLOAD <> '1'`: nu exista `ELSE`, se cade direct la
`HTTPURITYPE.createuri(tcURL).getclob()` (`URL2Clob`:367) / `getblob()` (`URL2Blob`:318). Pe URL
`https` fara wallet, asta da **mereu** `ORA-29273 / ORA-29024`.
**Consecinta - miezul sectiunii.** Codul de iesire al `curl.exe` (conexiune refuzata, timeout, 502)
e folosit doar ca sa se decida daca `.part` se redenumeste (linia 758); valoarea nu se logheaza si nu
se pastreaza nicaieri. Singurul semnal care ajunge inapoi la Oracle ramane `llDownloaded = FALSE`.
De aceea `ORA-29024` e zgomotul caderii, nu cauza, si cauza reala trebuie reconstruita din alta
parte (`v$session`, log-ul serverului de update).
**Ce sa verifici cand vezi ORA-29024**, in ordinea asta:
1. raspunde serverul de update pentru clientul ala? (`curl` de pe client, vezi mai sus);
2. `POWERSHELLDOWNLOAD` e `'1'` pe instanta clientului?
3. `ExecuteScriptOS` functioneaza pe instanta (POWERSHELLPATH completat, drepturi, directorul de
descarcare scriibil)? Un job `EXEC_PS_*` cu `SUCCEEDED` **nu** dovedeste ca si `curl` a reusit:
scriptul iese cu 0 si cand descarcarea a esuat. Un `<fisier>.part` ramas in DMPDIR arata ca
procesul nativ nu a fost asteptat.
4. abia la urma wallet-ul / certificatele - si numai daca cineva chiar vrea ramura 2.
## Incident 16.09.2026 (2): ROMFAST 10.0.20.36, acelasi simptom
Stare, nu concluzie.
**Fapt.** Pe serverul Oracle de productie ROMFAST (`10.0.20.36`) actualizarea esueaza cu stiva
`ORA-29273 / ORA-29024`, cu `PACK_UTILS` linia 313 si 305, `PACK_UPDATE` linia 323 si 180.
**Fapt (masurat de pe statia de lucru, 16.09.2026).** `curl https://roa.romfast.ro/contafinupdate/roaupdate/`
-> HTTP 200 in 0.127s; `curl http://10.0.20.122/` -> HTTP 404 in 0.0016s de la
`Microsoft-HTTPAPI/2.0`. Al doilea e normal - situl real e pe portul 81, cu ruta `/contafinupdate/...`,
iar 404-ul de la `http.sys` **nu** inseamna server picat. Deci serverul de update raspundea la ora
verificarii.
### Cauza: `&` nu asteapta procesul sub jobul extern
Configuratia era corecta: `POWERSHELLDOWNLOAD = 1`, `POWERSHELLTIMEOUT = 30`, `POWERSHELLPATH`
completat, NTFS pe `C:\DMPDIR` cu `Authenticated Users:(M)`. `sys.ExecuteScriptOS` functiona -
joburile `EXEC_PS_*` apar in `dba_scheduler_job_run_details` cu `SUCCEEDED`.
**Sub jobul DBMS_SCHEDULER `job_type => 'executable'` (proces fara consola), operatorul `&` din
PowerShell nu asteapta procesul nativ.** Masurat prin acelasi mecanism:
```
t0=23:07:08.671
t1=23:07:08.707 ec=[] exists=False <- la 36 ms dupa lansarea curl
t2=23:07:13.735 exists=True <- dupa Start-Sleep 5
```
Deci `$LASTEXITCODE` nu e niciodata setat, `if ($LASTEXITCODE -eq 0)` e FALSE (`$null -eq 0`), se
executa ramura `else` pe un fisier inca inexistent, iar `curl` termina descarcarea dupa ce scriptul
s-a incheiat si lasa `<destinatie>.part` pe disc definitiv. Fisierul destinatie nu apare niciodata ->
polling-ul expira dupa `POWERSHELLTIMEOUT` -> `HTTPURITYPE` -> `ORA-29273 / ORA-29024`.
Codul anterior scria cu `curl -o` direct in fisierul destinatie: neavand pas de redenumire, nu
depindea de terminarea lui `curl`, iar bucla de polling astepta oricum aparitia fisierului. Pasul
`Move-Item` introdus pe 16.09.2026 a facut ca asincronia sa conteze - de aceea simptomul apare la
prima rulare de dupa recompilare.
**Reparat** in `co_2026_09_16_06_COMUN_PACK_UTILS.sql`: lansarea asteapta explicit procesul si ii
citeste codul de iesire.
```powershell
$p = Start-Process -FilePath '<curl>' -ArgumentList '-k','-o','<dest>.part','<url>' -Wait -PassThru -NoNewWindow
if ($p.ExitCode -eq 0) { Move-Item ... } else { Remove-Item ... }
```
Dupa aplicare pe ROMFAST: `URL2Clob` intoarce documentul complet in ~2s, iar `PACK_UPDATE.UpdateROA`
s-a incheiat cu `UPDATEROA_JOB` SUCCEEDED.
**Ramas de verificat.** Capatul departat al db link-ului `DBL_ROMFAST2` este chiar `10.0.20.36`; la
incidentul conpress s-a omorat sesiunea de pe partea apropiata (ROA_CENTRAL), fara sa se fi privit
vreodata partea departata. Cele doua incidente pot avea radacini diferite - acesta nu il explica pe
celalalt.