¿Cuál es el uso de systemd-journal-flush.service?

Agradeceríamos tu apoyo para difundir nuestros ensayos sobre las ciencias informáticas.

Solución:

los systemd-journal-flush.service pide al daemon del diario que vacíe los datos de registro almacenados en /run/log/journal en /var/log/journal, si persistent el almacenamiento está habilitado. En caso de que (ya) tenga archivos de registro enormes, esto resultará en un arranque más lento. Más el disco (con /var/log) tiene que estar montado en un modo de escritura para hacerlo.

Para resumir: enormes archivos de registro antiguos, que se verifican durante el arranque y la adición de nuevos datos de registro da como resultado un tiempo de arranque más lento.

Para comprobar el tipo de tamaño de registro journalctl

journalctl --disk-usage

Para obtener la información de tiempo y espacio en disco del procesamiento de descarga, ingrese el siguiente comando

journalctl -b --unit systemd-journald

La salida correspondiente se verá como

-- Logs begin at Sat 2018-12-08 00:40:23 CET, end at Mon 2018-12-10 19:40:27 CET. --
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: Journal started
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: Runtime journal (/run/log/journal/265c93c062bf4c8da41abfe2ae793452) is 4.7M, max 38.3M, 33.5M free.
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: Time spent on flushing to /var is 7.066904s for 132 entries.
Dec 10 12:51:38 ubuntu01 systemd-journald[479]: System journal (/var/log/journal/265c93c062bf4c8da41abfe2ae793452) is 128.0M, max 256.0M, 128M free.

Tu también puedes

• Deshabilitar el servicio (no recomendado)

Entonces es posible que no todos los datos de registro se escriban en el disco; molesto al depurar fallos de arranque. Journald es un servicio fundamental en sistemad linux y muchos otros servicios dependen de ello.

• Verifique la consistencia interna del archivo de diario:

   journalctl --verify
  

Ojo que cada diario aparece PASAR.

• Utilizar una journalctl --vacuum mando

Desde journalctl -h

–vacuum-size=BYTES Reduce el uso del disco por debajo del tamaño especificado
–vacuum-files=INT Dejar solo el número especificado de archivos de diario
–vacuum-time=TIME Eliminar archivos de diario anteriores al tiempo especificado

Por lo tanto haz un

    sudo journalctl --vacuum-size=1G --vacuum-time=5d --vacuum-files=5

• Cambiar el tipo de almacenamiento de systemd-journal-flush.service

Primero verifique su tipo de almacenamiento con

     systemctl cat systemd-journal-flush.service  | grep -i storage

Desde man journald.conf

Almacenamiento =

Controla dónde almacenar los datos del diario. Uno de “volátil”, “persistente”, “automático” y “ninguno”.

Si “volátil“, los datos del registro diario se almacenarán solo en la memoria, es decir, debajo de la jerarquía /ejecutar/registro/diario (que se crea si es necesario).

Si “persistente“, los datos se almacenarán preferentemente en el disco, es decir, debajo de la jerarquía /var/log/journal (que se crea si es necesario), con un respaldo en /run/log/journal (que se crea si es necesario), durante el inicio temprano y si el disco no es grabable.

“auto” es similar a “persistente”, pero el directorio /var/log/journal no se crea si es necesario, por lo que su existencia controla dónde van los datos de registro.

“ninguna” apaga todo el almacenamiento, todos los datos de registro recibidos se eliminarán. Sin embargo, el reenvío a otros destinos, como la consola, el búfer de registro del kernel o un socket syslog, seguirá funcionando. El valor predeterminado es “automático”.

Edite el archivo

    sudo nano /etc/systemd/journald.conf

En la sección del diario, descomente y modifique:

    Storage=auto
    SystemMaxFileSize=1G
    SystemMaxFiles=5

recomendación

Recomiendo limitar el tamaño de la SystemMaxFileSize key a 20 MB –>

    SystemMaxFileSize=50M

Finalmente, en caso de que Ubuntu no se esté ejecutando en un servidor importante, sugiero cambiar el almacenamiento de datos a volátil:

    Storage=volatile

Si ejecuta el arranque en modo de depuración y realiza un seguimiento de las llamadas al sistema (strace), es posible que descubra que la escritura al ras tiene un rendimiento de E/S muy bajo. En mi caso no estaba claro por qué. Tal vez algunos mensajes del kernel envíen spam al archivo de registro (tenga en cuenta que después de 10000 mensajes, la unidad se bloquea de forma predeterminada, pero journald tiene que administrar esto, lo que puede causar un rendimiento deficiente). En ese caso, pase por alto los mensajes y busque los errores, que no necesariamente se han marcado como errores.

    journalctl -b --output short-monotonic

y

    journalctl -b -p 1..4 --output short-monotonic

los --output short-monotonicmarca imprime los pasos de tiempo en contraste con la hora utc predeterminada.

Finalmente, elimine los archivos de registro antiguos

    sudo rm -rf /var/log/journal

Guardar y reiniciar.

De acuerdo con esta publicación de la página de inicio del desarrollador de systemd, puede solucionarlo cambiando el archivo de la unidad.

Para ello, abra /lib/systemd/system/systemd-journal-flush.servicep.ej

sudo vim /lib/systemd/system/systemd-journal-flush.service

y cambiar el Antes de la dependencia desde

 Before=systemd-user-sessions.service systemd-tmpfiles-setup.service

para

 Before=systemd-tmpfiles-setup.service

Esta solución se modificará automáticamente para las versiones de systemd > v240.

No olvides guardar el archivo.

valoraciones y comentarios

---

---

Utiliza Nuestro Buscador