Tengo un servicio systemd que inicia sesión en stdout. A partir de ahí, systemd captura STDOUT y lo escribe en el diario.
Utilizo un modismo común para manejar un error en el que realizo echoalgunos diagnósticos y luego salgo con un código de error distinto de cero:
echo "my final error";
exit 1;
Mi problema es que esta última echolínea llega al diario, pero no está asociada correctamente con mi "unidad". Al mirar journalctl -o json-pretty, puedo ver cuál es la diferencia. El registro final carece de las propiedades _SYSTEMD_CGROUP y _SYSTEMD_UNIT.
Lo que creo que está sucediendo es una especie de condición racial. Sospecho que el script bash no espera journalda procesar completamente antes de pasar a la línea de salida. Entonces exitse alcanza la línea antes de journaldque termine de procesar la entrada del registro. journaldintenta buscar el unitque envió el registro, pero ahora no puede encontrarlo porque la unidad ya no está funcionando.
Si estoy en lo cierto, probablemente podría solucionar el problema poniéndolo sleep 1antes de mi exit 1declaración, pero ¿hay una mejor manera de atribuir la propiedad de registros final?
Estoy usando systemdla versión 229 en Ubuntu 16.04.
Respuesta1
@mark-stosberg, este es un problema conocido:journald no puede atribuir mensajes entrantes de procesos que salieron a su cgroup, debido a la carrera /proc vs SCM_CREDS
Puede encontrar una solución allí:https://github.com/systemd/systemd/issues/2913#issuecomment-219702148
intentar
SyslogIdentifier=Establece el nombre del proceso para prefijar las líneas de registro enviadas al sistema de registro o al búfer de registro del kernel.
y correr
journalctl _SYSTEMD_UNIT=unit + UNIT=unit + SYSLOG_IDENTIFIER=id
Respuesta2
Investigué esto y parece ser unproblema conocido con systemd que hay una solicitud de extracción para.
La solución implica almacenar en caché los metadatos del servicio, de modo que incluso si el servicio se ha cerrado, los metadatos todavía están disponibles para categorizar adecuadamente los últimos registros.
También se considera unerror abierto en CoreOS, que utiliza systemd.
El error también se rastrea en el rastreador de errores de systemd freedesktop.org como:
Pruebas adicionales encontraron que el problema de la atribución de registros faltante es más grave conusuariounidades... Supongo que es un tema aparte. Parasistemaunidades, la condición de carrera es relativamente pequeña y agregar sleep 1;justo antes de la salida en el script de servicio puede agregar suficiente relleno antes del último registro impreso y la salida para solucionar el problema.