Error ENOTFOUND caché

Expediente Electrónico Integrado SUDOCU - Técnicos
1

Hola buenas tardes, estamos en EEI v1.8.3 y SUDOCU v1.4.23.

Al parecer tenemos un inconveniente con el servicio de Redit. Cada vez que tenemos que reiniciar el servicio de SUDOCU, haciendo un redeploy, el sistema queda colgado en pantalla en blanco y no logramos acceder a la pantalla de inicio.

Buscando logs en el api-server pude encontrar lo siguiente:

Error: getaddrinfo ENOTFOUND cache
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) {
errno: -3008,
code: ‘ENOTFOUND’,
syscall: ‘getaddrinfo’,
hostname: ‘cache’
}
GET /auth/sesion 500 3.060 ms - 232
(node:1) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 1)
err Error: getaddrinfo ENOTFOUND cache
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26) {
errno: -3008,
code: ‘ENOTFOUND’,
syscall: ‘getaddrinfo’,
hostname: ‘cache’
}
GET /auth/logout 500 1.206 ms - 232
GET /auth/providers 200 2.791 ms - 13
GET /auth/providers 200 1.488 ms - 13
GET /auth/saml 302 15.813 ms - 0
[2025-01-20T11:55:12] error_redis_create {
details: null,
stack: ‘Error: getaddrinfo ENOTFOUND cache\n’ +
’ GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:107:26)',
string: ‘getaddrinfo ENOTFOUND cache’,
clientmessage: ‘getaddrinfo ENOTFOUND cache’,

El sistema logra arrancar luego de varios intentos al hacer deploy (a veces demasiados) y el error desaparece.

Quería consultar por qué se da esto? Si es por el orden en el cual se iniciar los servicios o tendremos alguna configuración errada en el sudocu.yml?

Esto es una complicación para nosotros al querer reiniciar SUDOCU ya que a veces tardamos mucho tiempo para que el sistema vuelva a estar disponible.

Desde ya, muchas gracias.

2

Buenas tardes, por lo que muestra el error es como bien decís, se debe a que el servicio cache de sudocu no está disponible todavía. No significa que haya algo mal configurado, a veces simplemente puede pasar.

Lo que se puede hacer para que sudocu levante más rápido cada vez que por algún motivo haya que levantar sudocu y no tengas que hacer varios intentos, es al levantar sudocu, eliminar inmediatamente los servicios sudocu_api-server y sudocu_api-worker, luego hacer el redeploy (lleva solo unos segundos extra pero garantiza que no tengas ese error).

La secuencia sería esta:

  1. deploy normal:

    docker stack deploy --with-registry-auth --compose-file prod/sudocu/sudocu.yml sudocu

  2. eliminar servicios

    docker service rm sudocu_api-server sudocu_api-worker

  3. deploy (para levantar esos 2 servicios eliminados)

    docker stack deploy --with-registry-auth --compose-file prod/sudocu/sudocu.yml sudocu

Espero que sea de ayuda.
Saludos

3

Excelente solución!

Hasta ahora me funcionó en todas las oportunidades.

Gracias Eli.

4

Buenísimo, marco la respuesta como solución del tema.
Saludos!

5

Hola buenas, en un entorno de pruebas, actualizamos EEI de la v1.8.1 a la 1.8.3, y nos pasa este mismo error. Probamos la solución de este tema y no nos funciona.

Estos son los logs del servicio sudocu_api-server:

Iniciando Sudocu...

Usando secrets

Warning: connect.session() MemoryStore is not

designed for a production environment, as it will leak

memory, and will not scale past a single process.

(node:1) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 error listeners added to [Commander]. Use emitter.setMaxListeners() to increase limit

(Use `node --trace-warnings ...` to show where the warning was created)

ERROR DE PROGRAMACION 

 Error: Connection timeout

    at Socket.<anonymous> (/app/node_modules/@redis/client/dist/lib/client/socket.js:177:124)

    at Object.onceWrapper (node:events:631:28)

    at Socket.emit (node:events:517:28)

    at Socket._onTimeout (node:net:598:8)

    at listOnTimeout (node:internal/timers:569:17)

    at process.processTimers (node:internal/timers:512:7)

Redis client error: ConnectionTimeoutError: Connection timeout

    at Socket.<anonymous> (/app/node_modules/@redis/client/dist/lib/client/socket.js:177:124)

    at Object.onceWrapper (node:events:631:28)

    at Socket.emit (node:events:517:28)

    at Socket._onTimeout (node:net:598:8)

    at listOnTimeout (node:internal/timers:569:17)

    at process.processTimers (node:internal/timers:512:7)

                 _                     

                | |                    

 ___  _   _   __| |  ___    ___  _   _ 

/ __|| | | | / _` | / _ \  / __|| | | |

\__ \| |_| || (_| || (_) || (__ | |_| |

|___/ \__,_| \__,_| \___/  \___| \__,_|

                                       

                                       

version 1.4.23

http://sudocu.dev

GET /ping 200 93.315 ms - 13

GET /ping 200 85.551 ms - 13

GET /auth/sesion 401 2.608 ms - 23

GET /auth/logout 401 1.247 ms - 23

GET /auth/providers 200 4.282 ms - 13

GET /auth/providers 200 2.373 ms - 13

GET /auth/saml 302 23.045 ms - 0

[2025-02-26T10:59:53] error_redis_create  {

  details: null,

  stack: 'Error: Connection timeout\n' +

    '     Socket.<anonymous> (/app/node_modules/@redis/client/dist/lib/client/socket.js:177:124)\n' +

    '     Object.onceWrapper (node:events:631:28)\n' +

    '     Socket.emit (node:events:517:28)\n' +

    '     Socket._onTimeout (node:net:598:8)\n' +

    '     listOnTimeout (node:internal/timers:569:17)\n' +

    '    ',

  string: 'Connection timeout',

  clientmessage: 'Connection timeout',

Alguna otra idea para probar? estuvimos probando de eliminar todo, reiniciar, actualizar los servicios y tampoco funciona.

Gracias!!

6

Buen día, tienen replicado el servicio cache? se trata de una implementación en docker?
en caso de tener varios nodos, probar anclar el servicio cache al nodo manager.

7

Hola ya lo arreglamos! lo tenemos en docker swarm, todo escalado a 1, y en un mismo nodo (ya que es de pruebas).

Lo solucionamos eliminando el stack de sudocu, luego eliminando todas las imagenes docker que usa sudocu (para que las descargue nuevamente) y volviendo a desplegar.

Saludos y gracias

8

Muchas gracias por avisar!