es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

Problemas con GitLab Runner en Windows de 32 bits.

Tengo un problema con GitLab Runner en Windows de 32 bits. Los runners están en la versión 14.4.0 y nuestra instancia de GitLab está en la versión 14.4.1-ee. Los runners están vinculados a máquinas específicas que ejecutan Windows 10 Pro de 32 bits (10.0.19043), usan ejecutores de shell (PowerShell) y se ejecutan con privilegios administrativos completos (es decir, como usuario del sistema local). Esto está fuera de mi control.

De manera esporádica, y sin motivo aparente, los runners dejan de enviar tráfico de registro a nuestra instancia de GitLab. Deberían estar subiendo varios MB de registros. No veo intentos fallidos de subir registros en modo de depuración. No veo ninguna actividad de red que espere en WireShark. Esto podría correlacionar con problemas para cargar un controlador personalizado, pero no puedo afirmarlo con certeza.

La solución alternativa es aún más desconcertante. El siguiente protocolo soluciona el problema: elimine todos los runners utilizando la interfaz GitLab CI; desinstale el runner defectuoso; descargue un nuevo archivo binario de runner, regístrelo e instálelo. Si repito los mismos pasos, excepto sin descargar un nuevo binario, el problema persiste. Los archivos son idénticos cuando ejecuto una diferenciación binaria en ellos.

No he podido extraer información relevante de los registros de eventos del sistema o del tráfico de red. El problema solo afecta a nuestros runners en Windows de 32 bits. No afecta a Windows de 64 bits ni a runners en Linux, independientemente de la arquitectura. Parece ocurrir de manera esporádica, en el sentido de que no puedo correlacionarlo con nada interesante que suceda en las máquinas afectadas.

Claramente, algo sobre nuestros entornos de Windows de 32 bits es diferente y está causando que los runners funcionen mal. Simplemente no sé qué es. Apreciaría cualquier dirección para descubrir la fuente de este problema. El hecho de que descargar nuevos archivos binarios haga la diferencia me preocupa, pero no tengo ninguna razón para sospechar que nuestras máquinas hayan sido comprometidas.

Tags:  , , , ,

Answer

  1. Avatar for davy.ai

    Tengo un problema con GitLab Runner en Windows de 32 bits

    Estoy ejecutando la versión 14.4.0 de GitLab Runner y nuestra instancia de GitLab está en la versión 14.4.1-ee. Los runners están vinculados a máquinas específicas que ejecutan Windows 10 Pro de 32 bits (10.0.19043), usan ejecutores de tipo shell (PowerShell) y se ejecutan con privilegios administrativos completos (es decir, como usuario del sistema local).

    De manera esporádica, y sin ninguna razón discernible, los runners dejan de enviar tráfico de registro a nuestra instancia de GitLab. No veo intentos fallidos de cargar registros en modo debug. Tampoco veo ningún tráfico de red que esperaría en WireShark. Esto podría correlacionar con problemas para cargar un controlador personalizado, pero no puedo estar seguro. El “workaround” es eliminar todos los runners usando la interfaz de CI de GitLab; desinstalar el runner defectuoso; descargar un nuevo binario del runner, registrarlo e instalarlo. Si repito los mismos pasos, excepto sin descargar un nuevo binario, el problema persiste. Los archivos son idénticos cuando ejecuto una comparación binaria entre ellos.

    No he podido extraer información relevante de los registros de eventos del sistema ni del tráfico de red. El problema solo afecta nuestros runners en Windows de 32 bits. No afecta a Windows de 64 bits ni a runners en Linux, independientemente de la arquitectura. Parece que sucede de manera esporádica, en el sentido de que no puedo correlacionarlo con nada interesante que suceda en las máquinas afectadas.

    Estoy buscando cualquier dirección para descubrir la fuente de este problema. El hecho de que descargar nuevos binarios haga la diferencia me preocupa, pero no tengo ninguna razón para sospechar que nuestras máquinas han sido comprometidas.

Comments are closed.