Se ralentiza el tiempo de arranque de mi sistema.

¿Puedo desactivarlo?

¿Qué sucederá si lo deshabilito en el arranque?

Estoy usando Ubuntu versión 18.04.

boot systemd services

— vivek
fuente

El systemd-journal-flush.servicele pide al demonio de diario que vacíe los datos de registro almacenados en / run / log / journal en / var / log / journal, si el persistentalmacenamiento está habilitado. En caso de que tenga (ya) archivos de registro enormes, esto provocará un arranque más lento. Además, el disco (con /var/log) debe montarse en un modo de escritura para hacerlo.

Para resumir: grandes archivos de registro antiguos, que se comprueban durante el arranque y la incorporación de nuevos datos de registro resulta en un tiempo de arranque más lento.

Para verificar el tipo de tamaño de registro journalctl

journalctl --disk-usage

Para obtener la información de tiempo y espacio en disco del proceso de vaciado, 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 fallas de arranque.

Usa un journalctl --vacuumcomando

Desde journalctl -h

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

Por lo tanto hacer un
```
 sudo journalctl --vacuum-size=1G --vacuum-time=5d --vacuum-files=5
```

Cambiar 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 es " volátil ", los datos de registro de diario se almacenarán solo en la memoria, es decir, debajo de la jerarquía / run / log / journal (que se crea si es necesario).

Si es " persistente ", los datos se almacenarán preferiblemente en el disco, es decir, debajo de la jerarquía / var / log / journal (que se crea si es necesario), con un respaldo a / run / log / journal (que se crea si es necesario), durante arranque 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, de modo que su existencia controla dónde van los datos de registro.

" ninguno " apaga todo el almacenamiento, todos los datos de registro recibidos se descartarán. Sin embargo, el reenvío a otros destinos, como la consola, el búfer de registro del kernel o un zócalo syslog seguirá funcionando. El valor predeterminado es "auto".

Edite el archivo
```
sudo nano /etc/systemd/journald.conf
```
En la sección del diario, descomenta y modifica:
```
Storage=auto
SystemMaxFileSize=1G
SystemMaxFiles=5
```
Guardar y reiniciar.

— abu_bua
fuente

No veo por qué un archivo de registro enorme retrasaría el arranque se vuelca en el registro / run / log / diario, pero eso es sólo el registro desde el último arranque

— solsticio de

No estoy absolutamente seguro. También podría ser la dependencia (¿inútil?) De systemd-user-sessions-flush.service en systemd-user-sessions.service (consulte https://github.com/systemd/systemd/pull/10502). Sin embargo, experimenté que limitar el archivo de registro a menos de 1 GB acelera el tiempo de arranque. Leí el código systemd / journal / *, pero no encontré algo interesante.

— abu_bua

¿Quizás debido a la descompresión / compresión (lz4)? Otros datos de registro no se transmiten simplemente al archivo; se registra y una tabla hash para búsquedas más rápidas, objetos modificados, ...

— abu_bua

Creo que un comentario sobre cómo se relacionan los archivos de diario y / var / log podría ser útil; No lo tengo claro, pero me parece que el diario está registrando activamente y cuando está vaciado, ¿está escribiendo los datos activos en el disco en los archivos normales / var / log?

— pbhj

tiene razón, pero durante el arranque los datos no pueden escribirse en el disco, ya que el disco debe montarse primero.

— abu_bua

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 hacerlo, abra /lib/systemd/system/systemd-journal-flush.service, por ej.

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

y cambie la dependencia Antes de

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

 Before=systemd-tmpfiles-setup.service

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

No olvides guardar el archivo.

— abu_bua
fuente

¿Para qué sirve systemd-journal-flush.service?

Tu también puedes