# Depanare serverul de actualizari ROA (ROACENTRAL / contafinupdate)

Completeaza `depanare-pack-update.md`: acolo e vorba de ce se intampla **pe baza clientului**, aici
de ce se intampla **pe serverul care livreaza actualizarile**. Foloseste documentul asta cand
`PACK_UPDATE` esueaza cu erori de retea / HTTP, adica atunci cand clientul e in regula dar nu
primeste fisierele.

## Lantul complet, de la eroare la cauza

```
job UPDATEROA_ZILNIC -> PACK_UPDATE.UpdateROA
  -> PACK_UTILS.URL2Clob / URL2Blob
       daca SERVER_INFO.POWERSHELLDOWNLOAD = 1:
         -> PACK_UTILS.DownloadFileOS -> scrie C:\DMPDIR\download_file.ps1
            -> sys.ExecuteScriptOS -> powershell -> curl.exe -k -o <tmp> <url>
            -> asteapta max SERVER_INFO.POWERSHELLTIMEOUT secunde sa apara <tmp>
       daca fisierul NU apare (sau POWERSHELLDOWNLOAD <> 1):
         -> cade pe HTTPURITYPE.createuri(url).getclob()/getblob()
```

**Consecinta cea mai importanta:** pe un URL `https`, ramura de rezerva `HTTPURITYPE` **nu poate
functiona** - Oracle nu are wallet cu CA-urile, deci da mereu:

```
ORA-29273: nu s-a reusit solicitarea HTTP
ORA-29024: Validarea certificatului a esuat
ORA-06512: la "CONTAFIN_ORACLE.PACK_UTILS", linia 304   <- HTTPURITYPE
ORA-06512: la "CONTAFIN_ORACLE.PACK_UPDATE", linia 321  <- URL2Clob(roa_app.xml); 750 = roa_database.xml
```

**ORA-29024 NU inseamna ca e o problema de certificat.** Inseamna ca descarcarea cu `curl` a
esuat si s-a ajuns pe ramura moarta. Cauza reala e ca **serverul de actualizari nu a raspuns**.
Nu pierde timp cu wallet-uri si certificate pana nu ai verificat serverul.

Al doilea capcan: `UPD_ISTORIC` poate arata `stare=4` (incheiat) chiar si pentru rulari care au
esuat, iar `UPD_LOG` se goleste la fiecare rulare noua. Sursa de adevar pentru esec e
`user_scheduler_job_run_details` / `dba_scheduler_job_run_details` (`status`, `additional_info`).

## Primul lucru de verificat: chiar nu raspunde serverul?

De pe masina clientului (nu de pe statia ta - firewall-ul serverului filtreaza pe IP):

```
curl.exe -k -s -o NUL --max-time 20 -w "HTTP=%{http_code} t=%{time_total}" "https://roa.romfast.ro/contafinupdate/default.aspx/updroa/download/<CUSTOMERID>/roa_app.xml"
```

`HTTP=000` cu `t` egal cu `--max-time` = blocat (nu refuzat). `exit=28` = timeout.

Ultima comanda reala rulata de Oracle e in **`C:\DMPDIR\download_file.ps1`** pe serverul clientului
- contine URL-ul exact si numele fisierului tinta. Daca `.tmp`-ul corespunzator nu exista, stii
sigur ca descarcarea a picat.

`CUSTOMERID` si URL-urile efective le iei din baza clientului:

```sql
select varname, varvalue from optiuni where varname like 'UPD_URL%';
select name, value from server_info
 where name in ('POWERSHELLDOWNLOAD','POWERSHELLPATH','POWERSHELLTIMEOUT','DMPDIR','NAME');
```

Daca `OPTIUNI.UPD_URL_*` sunt completate, ele bat default-urile din `PACK_UPDATE`
(`http://10.0.20.122:81/...` intern / `http://83.103.197.79:3002/...` extern).

## Serverul: ROACENTRAL, 10.0.20.122

| Ce | Unde |
|---|---|
| acces | `ssh romfast@10.0.20.122` (OpenSSH for Windows, shell implicit **PowerShell**) |
| aplicatie | ActiveVFP, `D:\APPUPDATESERVERAVFP` (sit IIS "Default Web Site", pool `DefaultAppPool`) |
| cod rute updroa | `D:\APPUPDATESERVERAVFP\prg\rest\controllers\updroa.prg` (+ `.FXP`) |
| **log aplicatie** | `D:\APPUPDATESERVERAVFP\prg\rest\controllers\log.txt` |
| config | `D:\APPUPDATESERVERAVFP\appupdateserver.ini` (DSN, user, parole, caile de download) |
| fisiere livrate | `D:\ROAUPDATE\_UPDATE\` (si `ROA_APP_<id>.xml` / `ROASTART_APP_<id>.xml` per client) |
| loguri IIS | `C:\inetpub\logs\LogFiles\W3SVC1\u_ex<YYMMDD>.log` |

Testeaza **local pe server**, ocolind proxy-ul (roa.romfast.ro trece prin 10.0.20.36):

```powershell
curl.exe -k -s -o NUL --max-time 15 --resolve roa.romfast.ro:443:127.0.0.1 -w "HTTP=%{http_code} t=%{time_total} sz=%{size_download}" "https://roa.romfast.ro/contafinupdate/default.aspx/updroa/download/18/roa_app.xml"
```

Daca se reproduce asa, proxy-ul si reteaua sunt nevinovate.

**Testeaza mai multi clienti.** Daca unii merg si altii nu, nu e nici situl, nici pool-ul:
parcurge `17,18,19,29,105,118,121` pe aceeasi ruta si compara timpii.

Capcane de mediu, ca sa nu tragi concluzii gresite:
- portul **81** e filtrat de firewall pentru alte masini, desi `netstat` arata `0.0.0.0:81 LISTENING`.
  "Inchis de pe LAN" nu inseamna "sit oprit".
- pe portul 80 fara `Host:` corect primesti **404 de la `Microsoft-HTTPAPI/2.0`** (http.sys), pentru
  ca niciun sit nu prinde cererea. Nu inseamna ca IIS e picat.
- `Get-WebRequest` / `appcmd list requests` nu sunt instalate (`Not implemented`).
- `Get-Service` esueaza pentru contul `romfast` (drepturi), dar `Get-Website` / `Get-WebAppPoolState`
  merg.
- daca pool-ul ramane in starea `Stopping`, procesele `w3wp` blocate nu ies singure; le identifici
  cu `C:\Windows\System32\inetsrv\appcmd.exe list wp` si le opresti cu `Stop-Process -Id <pid> -Force`.

## Cauza gasita pe 16.09.2026: sesiune Oracle agatata pe db link

Simptom: **doar un client** (id 18, conpress) primea timeout la orice ruta; toti ceilalti erau
serviti in 0.2s. In `log.txt` cererile clientului blocat se opreau exact dupa
`GetCustomer <id>` (`updroa.prg:635`), fara linia `GetCustomer sql ...` (`updroa.prg:703`).

`GetCustomer` interogheaza `SOFT_SERII.VGEN_CONTRACTESUPORTTEHNIC` pe **ROA_CENTRAL
(10.0.20.121:1521/ROA)**, iar view-ul ia `data_inceput / data_sfarsit / incetat / suspendat`
peste **db link `DBL_ROMFAST2` -> `ROMFAST.CONTRACTE` pe 10.0.20.36**.

Diagnostic (de pe orice statie, nu e nevoie de tunel):

```
set TNS_ADMIN=D:\ROA\instantclient_19_18
D:\ROA\instantclient_19_18\sqlplus.exe -S -L soft_serii/<parola>@ROA_CENTRAL
```
```sql
select sid, username, program, machine, status, event, seconds_in_wait, blocking_session
  from v$session where username is not null and type='USER'
 order by status, seconds_in_wait desc;
```

Ce a iesit:

```
SID 199  SOFT_SERII  w3wp.exe  ACTIVE  single-task message        51770   (blocanta)
SID 148  SOFT_SERII  w3wp.exe  ACTIVE  cursor: pin S wait on X       69   blocked by 199
SID 246  SOFT_SERII  w3wp.exe  ACTIVE  cursor: pin S wait on X       66   blocked by 199
```

- `single-task message` = sesiunea asteapta un apel remote pe db link care nu se mai intoarce.
- Sesiunea agatata **tine pinul X pe cursorul SQL-ului ei**, deci orice cerere noua cu **exact
  acelasi text SQL** asteapta `cursor: pin S wait on X`.
- `updroa.prg` pune literalul in SQL (`... where id_client = 18`), nu bind variable. De aceea
  **blocajul afecteaza exact un client** si pare "problema doar la el". Cu bind variables ar fi
  blocat toti clientii deodata - mai vizibil, dar aceeasi cauza.

Detalii despre sesiunea vinovata:

```sql
select s.sid, s.serial#, to_char(s.logon_time,'DD.MM.YYYY HH24:MI:SS'), s.sql_id, s.event,
       s.seconds_in_wait
  from v$session s where s.sid = <SID>;
select sql_id, substr(sql_text,1,200) from v$sql
 where sql_id in (select sql_id from v$session where sid=<SID>);
```

`logon_time` da momentul exact in care s-au rupt lucrurile (aici 15.09.2026 20:30:25 UTC = 23:30
local, adica fix rularea jobului de actualizare al clientului).

**Deblocare** (ca SYS pe ROA_CENTRAL):

```sql
alter system kill session '<SID>,<SERIAL#>' immediate;
```

Dupa kill, totul revine imediat - nu e nevoie de restart de sit sau de recycle de pool.

### Ce NU rezolva, desi pare (verificat, s-a pierdut timp pe ele)

- restart sit IIS / `Restart-WebAppPool` - sesiunea blocata e pe serverul Oracle si supravietuieste
  omorarii lui `w3wp`;
- restart Windows pe serverul de update - acelasi motiv;
- wallet / certificate pe clientul Oracle - ORA-29024 e simptom, nu cauza;
- stergerea cache-ului local `D:\APPUPDATESERVERAVFP\data\contracte.dbf` + `.CDX` (e recreat singur
  de `updroa.prg:683-688`, deci e un test ieftin si reversibil, dar in cazul asta a fost negativ).

## Lista scurta de verificare

1. `user_scheduler_job_run_details` pe clientul afectat: care e eroarea reala si **din ce zi**.
2. `C:\DMPDIR\download_file.ps1` pe client: URL-ul exact; exista `.tmp`-ul?
3. `curl` de pe client pe acel URL: raspunde sau timeout?
4. Pe ROACENTRAL, `curl` local cu `--resolve`, pentru mai multi clienti: e global sau doar unul?
5. `log.txt` al aplicatiei: pana la ce linie ajunge cererea blocata.
6. `v$session` pe ROA_CENTRAL: `single-task message` / `cursor: pin S wait on X` /
   `blocking_session`. Cauta `seconds_in_wait` mare si compara `logon_time` cu ziua din pasul 1.
7. `alter system kill session` pe sesiunea blocanta; reverifica pasii 3-4.

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).