Tema: systemd
-
cgroups v2 en el host: comprobar el modo y leer los límites de recursos por unidad
Los runtimes de contenedores modernos y systemd dependen ambos de cgroups v2 (la jerarquía unificada) para aplicar límites de memoria y CPU. Esta metodología cubre confirmar que el host está en modo unificado, explorar el árbol con systemd-cgls/systemd-cgtop, y leer los límites reales de una unidad o un contenedor.
-
Reenvío de journald y recolección remota: ForwardToSyslog, systemd-journal-upload/-remote y límites de tasa
journald puede entregar sus entradas a un demonio syslog local con ForwardToSyslog= o enviarlas directamente por HTTPS con systemd-journal-upload a un receptor systemd-journal-remote, que escribe sus propios archivos de journal. Ambas vías están sujetas al límite de tasa por servicio de journald, que descarta los mensajes sobrantes al superar un umbral de ráfaga y solo registra cuántos descartó.
-
Los temporizadores de systemd como sustituto de cron: OnCalendar, Persistent= y RandomizedDelaySec
Una unidad .timer de systemd emparejada con un .service de tipo oneshot puede sustituir a una entrada de crontab, y además añade ejecuciones de recuperación tras un periodo de inactividad y una dispersión aleatoria entre los hosts de un parque. Esta metodología escribe, valida y habilita ese par de unidades, y explica qué hacen realmente Persistent= y RandomizedDelaySec=.
-
«Too many open files» (EMFILE) y el límite de descriptores de archivo
EMFILE, que se muestra como «Too many open files», indica que un proceso ha alcanzado su propio límite de descriptores de archivo abiertos a la vez, documentado como RLIMIT_NOFILE. El artículo explica cómo distinguir una fuga real de descriptores de un límite demasiado bajo y cómo aumentarlo en la shell, en PAM y en las unidades de systemd.
-
Dialectos de análisis de archivos .env: comillas, export, valores multilínea y expansión en cinco cargadores
Docker Compose, docker run --env-file, python-dotenv, el dotenv de Node, EnvironmentFile de systemd y el uso de source sobre el archivo en un shell aceptan archivos de aspecto similar, pero difieren en comillas, la palabra clave export, valores multilínea y expansión de ${VAR}.
-
Ejecutar contenedores Podman como servicios systemd con Quadlet
Quadlet permite que systemd administre contenedores Podman directamente a partir de archivos de unidad declarativos .container, en sustitución del flujo de trabajo en desuso podman generate systemd. Esta metodología cubre las ubicaciones de archivo para servicios de sistema y de usuario, la activación y la etiqueta de actualización automática.
-
La cadena de arranque de Linux para diagnóstico: firmware, gestor de arranque, kernel, initramfs y systemd
Un arranque de Linux pasa por el firmware, un gestor de arranque, el kernel, un initramfs y, por último, el gestor del sistema, y cada etapa cede el control a la siguiente. Saber qué hace cada una y dónde registra sus mensajes permite a un administrador acotar un arranque fallido a una sola etapa antes de modificar nada.
-
Comparativa de tareas programadas: cron, temporizadores de systemd, launchd, el Programador de tareas y cron/at de AIX
Cada planificador responde de forma distinta a una misma pregunta: ¿qué ocurre con una tarea cuyo momento programado pasó mientras la máquina estaba apagada o suspendida? Al comparar cron, los temporizadores de systemd, las claves de calendario de launchd y el Programador de tareas de Windows se observa que solo launchd recupera la ejecución tras la suspensión por defecto, y que los demás solo lo hacen si se configuran para ello.
-
systemd rescue.target y emergency.target: cómo entrar en ellos y volver al funcionamiento normal
rescue.target inicia el sistema base y un shell monousuario; emergency.target omite casi todo e inicia un shell en la consola, con el sistema de archivos raíz posiblemente aún en solo lectura. Se accede a ambos con el parámetro de kernel systemd.unit=, y en los dos casos hay que volver a default.target de forma explícita después.
-
Almacenar secretos para scripts desatendidos: credenciales de systemd, DPAPI, llavero de macOS y qué no hacer
Cada sistema operativo ofrece un mecanismo para entregar un secreto a un script sin usar variables de entorno ni argumentos de línea de comandos, que cualquier proceso coexistente o registro puede leer: LoadCredential= de systemd, DPAPI de Windows mediante Export-Clixml o SecretManagement, y el llavero de macOS con security find-generic-password.
-
Comparativa de gestores de servicios: systemd, launchd, el Service Control Manager, SRC y rc.d/OpenRC
Todo sistema operativo de propósito general cuenta con algo que inicia, detiene, supervisa y arranca los servicios, pero los comandos y el modelo de persistencia difieren. Esta referencia mapea el inicio, la detención, el estado, la activación en el arranque y el acceso a los registros entre systemd, launchd, el Service Control Manager de Windows, el SRC de AIX, y el rc.d de FreeBSD y el OpenRC de Alpine.
-
Consultar el journal de systemd con journalctl: unidad, arranque, prioridad, intervalo de tiempo y salida JSON
journalctl puede filtrar el journal de systemd por unidad, arranque, prioridad e intervalo de tiempo, y generar una salida legible por máquina, pero solo si el journal está configurado para persistir entre reinicios. Esta metodología cubre las consultas precisas, el almacenamiento persistente y los límites de tamaño en journald.conf.
-
Identificar un host Linux desconocido antes de cambiar nada en él
Antes de que un agente o una persona operadora cambie la configuración de una máquina Linux que no construyó, debería establecer la distribución, el kernel, el estado de virtualización o contenedor, el sistema de init, el gestor de paquetes y el estado del control de acceso obligatorio, cada uno con un comando barato y no destructivo.
-
Editar /etc/fstab con seguridad: UUID, nofail, opciones x-systemd y findmnt --verify
Una línea incorrecta en /etc/fstab puede dejar el sistema en una shell de emergencia en el siguiente arranque. Esta metodología usa UUID= en lugar de nombres de dispositivo, nofail y x-systemd.device-timeout= para montajes opcionales, y findmnt --verify junto con mount -a para probar el archivo antes de reiniciar.
-
Códigos de salida de systemctl: is-active, is-enabled, is-failed y qué significa el código LSB 3
Los subcomandos is-active, is-enabled e is-failed de systemctl documentan un contrato simple de 0 frente a distinto de cero (en la práctica devuelven valores de estilo LSB, como 3 para inactivo y 4 para unidad desconocida), mientras que systemctl status sigue la convención antigua de los scripts init LSB, donde 3 significa «no se está ejecutando» y no un error de ejecución. Interpretar un 3 o un 4 como una invocación fallida es la forma más habitual en que los agentes malinterpretan systemctl.
-
Cadenas de duración e intervalo: ISO 8601, ParseDuration de Go, systemd, Prometheus, PostgreSQL y TimeSpan de .NET
PT1H30M, 1h30m, '1h 30min' y 01:30:00 pueden describir el mismo lapso, pero cada parser acepta un conjunto distinto de sufijos de unidad y rechaza todo lo demás, así que una cadena de duración copiada entre sistemas suele fallar al interpretarse.
-
Cómo interpretar la presión de memoria en Linux: free, swap, el OOM killer y OOMScoreAdjust
La columna «available» de free, y no «free», es la cifra que indica el margen real de memoria, y un proceso terminado por presión de memoria deja un registro en el log del kernel o en el journal, no desaparece sin dejar rastro. Este artículo explica qué consultar y cómo influir en qué proceso elige el OOM killer.
-
Diagnóstico de la resolución de nombres en un host con systemd: resolvectl, resolv.conf, nsswitch y getent frente a dig
En un host con systemd-resolved, /etc/resolv.conf normalmente solo apunta a un stub local, los servidores DNS reales por enlace se consultan con resolvectl, y /etc/nsswitch.conf decide si getent hosts llega siquiera a preguntar al DNS. Confundir estas capas explica la mayoría de los casos de «dig funciona pero la aplicación no».
-
Configurar parámetros del kernel de Linux con sysctl: cambios en tiempo de ejecución frente a /etc/sysctl.d
sysctl -w cambia un parámetro del kernel solo hasta el próximo reinicio; para que el cambio sea persistente hay que colocar un archivo en /etc/sysctl.d/ y entender el orden de carga entre /usr/lib, /etc y /run. sysctl --system aplica todos los archivos configurados e indica cuál prevalece en caso de conflicto.
Legible por máquina: JSON