3 · Infraestructura·6 min de lectura
Las licencias que nadie estaba usando
H0038: las licencias a que tiene derecho están ocupadas, reintente más tarde.
Contabilidad no podía entrar a Cuentas por Pagar. Tenían dos licencias del módulo. Nadie lo tenía abierto. Llevaban así desde el fin de semana, y el mensaje decía que estaban ocupadas, no por quién ni desde cuándo.
Primera evidencia: la base de datos#
Microsip corre sobre Firebird, y Firebird lleva su propia lista de conexiones abiertas en la tabla de sistema MON$ATTACHMENTS. Ahí no hay opiniones:
ID USUARIO PROCESO DESDE ANTIGÜEDAD
28316 USUARIO-A Cxp.exe 01-sep 16:41 144 horas
28478 USUARIO-A Cxp.exe 03-sep 19:50 93 horas
28314 USUARIO-A Cxc.exe 01-sep 16:39 144 horas
Doce conexiones abiertas de la misma persona. La más vieja llevaba seis días. Ninguna era de ese día. Dos correspondían a Cxp.exe, el ejecutable de Cuentas por Pagar. Dos licencias, dos sesiones muertas.
Eso explicaba el síntoma. No la causa: ¿por qué sobrevive una conexión seis días a la persona que la abrió?
Segunda evidencia: Windows#
La respuesta estaba una capa más abajo. query session en el servidor:
console consola 57 Activo
cuenta-a 287 Desconectada
cuenta-b 319 Desconectada
rdp-tcp#4 cuenta-c 336 Activo
query session es el comando de Windows que pregunta quién tiene una sesión abierta en el servidor. «Desconectada» no significa cerrada: significa que la persona se fue y sus programas siguen corriendo.Tres sesiones de escritorio remoto llevaban días desconectadas. No cerradas: desconectadas. Y una sesión desconectada de Windows conserva todos sus programas corriendo, indefinidamente.
tasklist cerró el círculo: los procesos que ocupaban las licencias vivían en las sesiones 287 y 319, las mismas de la lista anterior.
La causa: cerrar la ventana no es cerrar sesión#
Cuando alguien cierra la ventana del escritorio remoto, Windows deja la sesión viva "por si vuelve". Sin límite. Nadie hizo nada mal — es el comportamiento por omisión, y no da ninguna señal hasta que alguien no puede trabajar.
Y en el chat interno de la empresa estaba la prueba de que no era la primera vez: "Me pueden prestar una licencia porfavor", once días antes. Lo venían resolviendo pidiéndose turnos.
El segundo eslabón, que casi se nos pasa#
Cerramos los dos procesos muertos y Cuentas por Pagar se liberó. Una hora después, Cuentas por Cobrar seguía bloqueado con cero conexiones en Firebird.
Microsip no licencia por conexión a la base: usa Sentinel LDK, un gestor aparte que lleva su propia contabilidad. Su consola local lo mostraba en claro:
"fn":"Cuentas por cobrar", "usr":"cuenta-b", "pid":"17212", "lt":"Thu Sep 3"
lt es la última vez que dio señales de vida: llevaba días sin moverse y la licencia seguía apartada.Sesiones de licencia de procesos que ya habíamos matado. Sentinel no se entera de que el programa murió: la retiene hasta que vence su propio plazo, que estaba en 720 minutos. Doce horas.
Qué hicimos#
Desatoro inmediato: taskkill /PID sobre los procesos huérfanos, logoff de las dos sesiones abandonadas, y reinicio del servicio hasplms para que Sentinel soltara lo que retenía. De doce sesiones colgadas a cero.
Y los dos límites que no venían de fábrica, uno por eslabón:
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" ^
/v MaxDisconnectionTime /t REG_DWORD /d 14400000 /f (4 horas)
hasplm.ini: idle_session_timeout_mins = 720 -> 120 (2 horas)
Antes, una licencia abandonada quedaba tomada para siempre. Ahora se libera sola el mismo día. Y si alguien cierra sesión al terminar en vez de solo cerrar la ventana, se libera al instante.
Encima, un vigilante horario que consulta MON$ATTACHMENTS y avisa cuando la sesión de un módulo lleva más de 12 horas sin uso, nombrando el módulo, el usuario y el PID a cerrar. El aviso llega antes de que alguien choque con el error.
Lo que nos llevamos#
Esto no era sobre licencias. Era sobre un recurso que se toma solo y no se libera nunca, con dos agravantes que lo vuelven invisible: la señal llega días tarde y sin nombrar al culpable, y la causa vive en una capa distinta de donde salió el error.
Cuando algo se agota sin que nadie lo consuma, la pregunta no es quién lo está usando. Es qué lo tomó y nunca lo soltó — y casi siempre hay dos eslabones, no uno.