Introducción al revista Systemd
- 2773
- 887
- Sra. Lorena Sedillo
Systemd hoy es el sistema init adoptado por casi todas las distribuciones de Linux, desde Red Hat Enterprise Linux hasta Debian y Ubuntu. Una de las cosas que hizo que Systemd sea el objetivo de muchos críticos es que intenta ser mucho más que un sistema inicial simple e intenta reinventar algunos subsistemas de Linux.
El sistema de registro tradicional utilizado en Linux, por ejemplo, fue rsyslog, una versión moderna del tradicional syslog. Systemd introdujo su propio sistema de registro: es implementado por un demonio, diario, que almacena registra el formato binario en un "diario", que puede ser consultado por el Journalctl utilidad.
En este tutorial aprenderemos algunos parámetros que podemos usar para modificar el diario Comportamiento del demonio y algunos ejemplos de cómo consultar el diario y formatear la salida resultante de dichas consultas.
En este tutorial aprenderás:
- Cómo cambiar la configuración predeterminada de Journald
- Cómo Journald puede coexistir con syslog
- Cómo consultar el diario y algunas formas de formatear la salida de consultas
Requisitos y convenciones de software utilizados
Categoría | Requisitos, convenciones o versión de software utilizada |
---|---|
Sistema | Una distribución de Linux usando Systemd (casi todos lo hacen) |
Software | No se necesita un software específico |
Otro | Privilegios raíz a (eventualmente) cambiar las configuraciones predeterminadas |
Convenciones | #: los comandos de Linux se ejecutarán con privilegios raíz directamente como un usuario raíz o mediante el uso de sudo dominio$-Linux Commands para ser ejecutado como un usuario no privilegiado regular |
Archivo de configuración de Journald
El comportamiento de la diario Daemon se puede modificar cambiando la configuración en su archivo de configuración: /etc/systemd/Journald.confusión
. No se recomienda la modificación directa de este archivo; En su lugar, debemos crear algunos archivos de configuración separados que contienen los parámetros que pretendemos cambiar, guárdelos con el .confusión
extensión y colóquelos dentro del /etc/systemd/Journald.confusión.d
directorio.
Los archivos colocados dentro del /etc/systemd/Journald.confusión.d
El directorio tiene una precedencia mayor que /etc/systemd/Journald.confusión
: Están ordenados por su nombre en orden lexicográfico y analizado en ese orden, todo después del archivo principal. En caso de que exista la misma configuración de opción en más de un archivo, el último en analizar será efectivo.
El /etc/systemd/Jourlnald.confusión
El archivo, por defecto, contiene una lista comentada de opciones dentro del [Diario]
Estrofa: representan los valores predeterminados utilizados en el tiempo de compilación (el contenido a continuación es de un sistema Fedora):
[Journal] #Storage = Auto #compress = Yes #sell = sí #SplitMode = UID #SyncInterValSec = 5M #RatElimitIntervalSec = 30s #RatElimitBurst = 10000 #Systemmaxuse = #Systemkeepfree = # #SystemMaxFilesize = # #SystemMaxFiles = 100 #RuntimeMaxuse = #runtimekeepfree = = #RuntimemaxFilesize = #runtimeMaxFiles = 100 #maxretentionsec = #maxfileseC = 1Month #flowtosyslog = no #flowTokmsg = no #foresteToconsole = no #hacia adelante MaxLevelConsole = info #maxlevelwall = emerg #linemax = 48k #readkmsg = sí #audit = sí
Veamos cuál es el significado de algunas de esas opciones y cómo pueden cambiar el comportamiento del diario demonio.
La opción "Almacenamiento"
La primera opción que encontramos en el archivo es Almacenamiento. Esta opción controla dónde se almacenan los datos del revista. El valor predeterminado utilizado en el tiempo de compilación aquí es auto
, Pero es posible elegir entre:
- volátil
- persistente
- auto
- ninguno
Si usamos volátil
Como el valor de esta opción, los datos de la revista se almacenarán solo en la memoria bajo /ejecutar/log/Journal
(/correr
es un TMPFS: su contenido se almacena en la memoria), por lo que no sobrevivirá a un reinicio del sistema.
Si persistente
en su lugar se utiliza, los datos del revista se almacenarán en el disco, debajo /var/log/Journal
, que se crea si no existe. Si por alguna razón el disco no es escribido, sin embargo, /ejecutar/log/Journal
se usa como alternativa.
El auto
valor para el Almacenamiento
La opción, que aquí se usa como predeterminada, funciona básicamente como persistente
En el sentido de que cuando se usa, los datos del revista se almacenan en /var/log/Journal
. La diferencia es que si la ruta no existe, no se crea y los registros se almacenarán solo en la memoria.
Finalmente, si el ninguno
Se utiliza el valor, todo el almacenamiento se desactiva: mientras se reenvía a otros sistemas de registro como syslog seguirá funcionando, todos los datos recibidos se eliminarán.
La opción "Compresar"
La opción de "comprimir" controla si los datos que exceden el umbral de 512
bytes se comprime antes de almacenarse en el disco. Esta opción acepta dos tipos de valores: un booleano Como en el caso anterior (Sí
), o un número que establece el umbral de compresión en sí. Si se proporciona este último, la compresión se activa implícitamente. El valor umbral es, por defecto, expresarse en bytes, pero el K
, METRO
o GRAMO
Los sufijos se pueden usar en su lugar.
La opción "Forwardtosyslog"
Como ya se mencionó, en la era previa al sistema, los registros administrados por el syslog
sistema de registro (rsyslog
de hecho). Este sistema de registro puede reenviar registros a muchos destinos, como archivos de texto, terminales o incluso otras máquinas en la red. Systemd implementó su propio sistema de registro, que es el objeto de este tutorial: diario.
Los dos sistemas pueden coexistir (esto a veces es necesario ya que Journald pierde algunas características como registro centralizado, o solo porque nosotros, como a los administradores, nos gustan los registros que se almacenarán en archivos de texto en lugar de en formato binario, para que puedan ser manipulados con herramientas de Unix estándar).
Este AvenTosyslog
La opción toma un booleano Valor: si se establece en Sí
, Los mensajes se reenviarán al /run/systemd/Journal/syslog
socket, ¿dónde se puede leer por syslog
. Este comportamiento también se puede establecer en el arranque a través del system.diario.hacia adelante_to_syslog
opción.
Se pueden usar opciones similares para reenviar mensajes a KMSG
(buffer de registro del kernel), a la consola o a "muro" (enviado como mensajes de registro a los usuarios registrados). Solo este último está configurado para Sí
por defecto.
Consulta el diario
La herramienta que podemos usar para examinar los registros del sistema y la consulta que es el Systemd Journal Journalctl
. Si se llama al comando sin más parámetros, se muestra todo el contenido del diario. Afortunadamente, se pueden implementar varias estrategias para filtrar los registros. Veamos algunos de ellos.
Filtrando mensajes por unidades
Una de las opciones más útiles a las que podemos pasar Journalctl
es -u
, ¿Cuál es la versión corta de --unidad
. Con esta opción podemos filtrar el contenido de la revista para que solo los mensajes del específico Unidad Systemd aprobado como se devuelve el argumento de opción. Por ejemplo, para mostrar solo mensajes que provienen del Gerente de Redes.servicio
Unidad, podemos ejecutar:
$ Journalctl -U NetworkManager-Los registros comienzan en el miércoles 2020-07-01 21:47:23 CEST, finalizar en el sábado 2020-07-25 15:26:59 CEST. -- 01 de julio 21:48:07 ERU Systemd [1]: Iniciar administrador de la red ... 01 de julio 21:48:07 ERU NetworkManager [1579]: [1593632887.7408] NetworkManager (versión 1.22.10-1.FC32) está comenzando ... (por primera vez) 01 de julio 21:48:07 ERU NetworkManager [1579]: [1593632887.7413] leer configuración:/etc/networkManager/networkManager.conf Jul 01 21:48:07 ERU Systemd [1]: Iniciado Network Manager.
Además, una opción específica se dedica a filtrar solo los mensajes del núcleo: -k
, ¿Cuál es la forma corta de --dmesg
.
Filtrado de registros por fecha
Si queremos filtrar los mensajes almacenados en el diario por fecha, podemos usar dos opciones dedicadas: -S
(corto para --desde
) y -U
(corto para --hasta
). Ambas opciones aceptan una fecha en el formato Yyyy-mm-dd HH: mm: ss
. Se puede omitir la parte de "hora" de la fecha, y en ese caso 00:00:00
se supone. Supongamos que queremos filtrar los registros a partir de la fecha actual; Ejecutaríamos el siguiente comando:
$ Journalctl --since 2020-07-25
Para restringir aún más los registros con un tiempo de 16:04:21
a 16:04:26
:
$ Journalctl --since "2020-07-25 16:04:21" --Util "2020-07-25 16:04:26"
También existen una serie de alias: se pueden usar en lugar de fechas simples:
Cadena | Significado |
---|---|
"ayer" | 00:00:00 del día antes del actual |
"hoy" | el día actual |
"mañana" | el día después del actual |
"ahora" | la hora actual |
Mostrando solo los últimos registros
Si lanzamos el Journalctl
comando con el -F
(--seguir
) Opción, podemos visualizar solo los últimos registros recibidos, y aún así observar a medida que se adhieren nuevos registros (básicamente es como llamar a cola
con el -F
opción). Por otro lado, si solo queremos visualizar el final del diario, podemos usar el -mi
opción (--tarta
).
Formateo de la salida de diario
La salida que recibimos al usar Journalctl
Se puede formatear fácilmente utilizando una opción dedicada: -O
, o su versión larga, --producción
. Al usar esta opción, podemos especificar entre una serie de "estilos". Entre los (muchos) otros:
- corto
- verboso
- JSON Pretty
El corto
El formato es el valor predeterminado: se muestra una línea por entrada en una salida similar a la del syslog tradicional:
01 de julio 21:48:07 ERU Systemd [1]: Iniciar Administrador de red ..
El verboso
El formato, en cambio, hace que se muestren todos los campos de la entrada:
Mié 2020-07-01 21:48:07.603130 CEST [s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d;m=2e82666;t=5a966922b0155;x=6668aad5e895da03] PRIORITY=6 _BOOT_ID=1c06b8c553624a5f94e1d3ef384fb50d _MACHINE_ID=afe15f1a401041f4988478695a02b2bf _HOSTNAME=eru SYSLOG_FACILITY=3 SYSLOG_IDENTIFIER=systemd _UID=0 _GID= 0 _transport = Journal _Cap_Effective = 3fffffffff code_file = src/core/trabajo.c code_line = 574 code_func = job_log_begin_status_message Job_type = start Message_id = 7d4958e842da4a758f6c1cdc7b36dcc5 _pid = 1 _comm = systeme =/usr/systemd/systemd _systemd _systemd _systemd _systemd _systemd_cegry.alcance _systemd_unit = init.alcance _systemd_slice =-.Slice _Selinux_Context = System_u: System_r: init_t: s0 _cmdline =/usr/lib/systemd/systemd--switched-root --system --serialize 34 Message = Iniciar administrador de red ... Job_id = 243 Unit = NetworkManager.servicio invocation_id = 6416439e51ff4543a76bded5984c6cf3 _source_realtime_timestamp = 1593632887603130
El JSON Pretty
El formato muestra las entradas como Json objetos de una manera legible. En este formato, las entradas están separadas por una nueva línea:
"__Realtime_timestamp": "1593632887603541", "prioridad": "6", "_systemd_unit": "init.alcance "," _systemd_cgroup ":"/init.alcance "," _Uid ":" 0 "," _comm ":" systemd "," _systemd_slice ":"-.slice", "_CAP_EFFECTIVE" : "3fffffffff", "_BOOT_ID" : "1c06b8c553624a5f94e1d3ef384fb50d", "_SELINUX_CONTEXT" : "system_u:system_r:init_t:s0", "__CURSOR" : "s=d61cdf3710e84233bda460d931ebc3bb;i=6be;b=1c06b8c553624a5f94e1d3ef384fb50d; m = 2e82666; t = 5a966922b0155; x = 6668aad5e895da03 "," _hostname ":" eru "," _pid ":" 1 "," message_id ":" 7D4958e842da4a4a758f6c1cdc7b36dcc5 ",", ",", ",", ",", ",", ",", ",", ",", ",", ",", ". Iniciar administrador de red ... "," _exe ":"/usr/lib/systemd/systemd "," __monotonic_timestamp ":" 48768614 "," _transport ":" diario "," syslog_facility ":" 3 ",": ":": " Gerente de Redes.Servicio "," Job_id ":" 243 "," Job_type ":" Inicio "," _gid ":" 0 "," Code_File ":" Src/Core/Job.c", "_MACHINE_ID" : "afe15f1a401041f4988478695a02b2bf", "_CMDLINE" : "/usr/lib/systemd/systemd --switched-root --system --deserialize 34", "SYSLOG_IDENTIFIER" : "systemd", "CODE_LINE" : "574", "invocation_id": "6416439e51ff4543a76bded5984c6cf3", "_source_realtime_timestamp": "1593632887603130"
Conclusiones
En este tutorial nos acercamos diario el demonio systemd que implementa el diario de registro. Este sistema de registro está destinado a usarse en lugar de syslog, que era el sistema tradicional utilizado en Linux. En muchas distribuciones, por una razón u otra, los dos sistemas aún coexisten.
Vimos lo que es el diario Archivo de configuración y cuál es el significado de algunas opciones importantes que se pueden usar para modificar su comportamiento, y aprendimos cómo podemos consultar el Systemd Journal con el Journalctl utilidad. Si quieres saber más sobre diario y Journalctl. Le sugiero que lea los manuales respectivos (Man Journald.confusión
y Man JournalCtl
son los comandos que está buscando).
Tutoriales de Linux relacionados:
- Registro avanzado y auditoría en Linux
- Cosas para instalar en Ubuntu 20.04
- Archivos de configuración de Linux: los 30 principales más importantes
- Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
- Descarga de Linux
- Una introducción a la automatización, herramientas y técnicas de Linux
- Cosas que hacer después de instalar Ubuntu 22.04 Jellyfish de Jammy ..
- ¿Puede Linux obtener virus?? Explorando la vulnerabilidad de Linux ..
- La mejor distribución de Linux para desarrolladores
- Cosas para instalar en Ubuntu 22.04
- « Cómo rastrear las llamadas del sistema realizadas por un proceso con Strace on Linux
- Cómo crear archivos encriptados comprimidos con alquitrán y GPG »