Servicios y registros

1. Servicios, systemd y unidades

Un servicio, o demonio, es un programa que se ejecuta en segundo plano de manera permanente, sin terminal ni usuario que lo atienda, a la espera de trabajo: una conexión que llega, una hora que se cumple, un dispositivo que se conecta.

En el tema 33 aprendimos a dejar un programa en segundo plano con & y con nohup, y dijimos que eran soluciones de emergencia. Un servicio necesita más que sobrevivir al cierre de la terminal: debe arrancar solo con la máquina, en el orden correcto respecto de otros, volver a arrancar si se cae, y dejar constancia de lo que hace. De todo eso se ocupa un único programa.

systemd es el primer proceso que el kernel pone en marcha, el de PID 1, y el administrador de todo lo demás: inicia los servicios al arrancar, los supervisa mientras funcionan, los detiene al apagar y recoge sus mensajes. Cada cosa que administra se llama unidad.

Lo vimos en la raíz del árbol de procesos del tema 32. Lo usan Ubuntu, Debian, Fedora, Red Hat, Arch y openSUSE, de modo que este tema, como el 37 y el 38, vale para casi todas las distribuciones. Las unidades son de varias clases, que se distinguen por el sufijo de su nombre:

Las del primer tipo son las que interesan, y por eso systemctl permite omitir el sufijo: cron se entiende como cron.service. systemctl, de system control, es el comando con que se le dan órdenes a systemd, y journalctl, el que lee los mensajes que systemd recoge. Son los dos comandos del tema.

Como ejemplo usaremos cron, el servicio que ejecuta las tareas programadas. Está en todos los sistemas, y detenerlo un minuto no causa ningún problema.

2. systemctl status: la ficha de un servicio

Lo usamos como ejemplo de subcomando en el tema 3, sin explicarlo. Es el comando más útil del tema, y no requiere sudo.

$ systemctl status cron
● cron.service - Regular background program processing daemon
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-10-13 08:29:14 -03; 2h 31min ago
       Docs: man:cron(8)
   Main PID: 842 (cron)
      Tasks: 1 (limit: 9264)
     Memory: 1.1M (peak: 4.6M)
        CPU: 312ms
     CGroup: /system.slice/cron.service
             └─842 /usr/sbin/cron -f -P

oct 13 08:29:14 equipo systemd[1]: Started cron.service - Regular background program processing daemon.
oct 13 08:29:14 equipo cron[842]: (CRON) INFO (pidfile fd = 3)
oct 13 08:29:14 equipo cron[842]: (CRON) INFO (Running @reboot jobs)
oct 13 09:17:01 equipo CRON[5121]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
oct 13 10:17:01 equipo CRON[6340]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)

En una pantalla está casi todo lo que se puede preguntar de un servicio: si funciona, desde cuándo, con qué procesos, cuánto consume y qué fue lo último que dijo. Las dos palabras resaltadas responden dos preguntas distintas, que conviene no confundir y que retomamos en la sección 6: active dice que está funcionando ahora; enabled, que arrancará solo en el próximo inicio.

La línea CGroup muestra algo que ps no puede: systemd coloca cada servicio en un grupo propio, y sabe en todo momento qué procesos le pertenecen, aunque el servicio haya lanzado hijos y nietos. Por eso puede detenerlos a todos sin dejar ninguno suelto.

Si la salida ocupa más que la pantalla, systemctl la muestra con el paginador less, y se sale con q. Con --no-pager escribe todo de una vez, y con -n 20 se eligen cuántas líneas de registro mostrar.

3. Los estados, y las preguntas de sí o no

La línea Active lleva dos palabras: el estado general y, entre paréntesis, el detalle.

La diferencia entre inactive y failed es la que importa: un servicio detenido está donde alguien lo dejó; uno fallado quiso funcionar y no pudo.

Para preguntar por un solo dato hay tres subcomandos que responden una palabra, y que además comunican la respuesta por el código de salida del tema 25, lo que los hace aptos para encadenar con && y ||:

$ systemctl is-active cron
active
$ systemctl is-enabled cron
enabled
$ systemctl is-active cron ssh snapd      # varios a la vez
active
inactive
active
$ systemctl is-active --quiet cron && echo "cron funciona" || echo "cron está caído"
cron funciona

4. Listar los servicios

Para ver el conjunto, systemctl list-units enumera las unidades que systemd tiene cargadas. Sin filtro son varios centenares, de todos los tipos; con dos opciones queda lo que se busca:

$ systemctl list-units --type=service --state=running
  UNIT                      LOAD   ACTIVE SUB     DESCRIPTION
  accounts-daemon.service   loaded active running Accounts Service
  cron.service              loaded active running Regular background program processing daemon
  dbus.service              loaded active running D-Bus System Message Bus
  NetworkManager.service    loaded active running Network Manager
  rsyslog.service           loaded active running System Logging Service
  snapd.service             loaded active running Snap Daemon
  systemd-journald.service  loaded active running Journal Service
  unattended-upgrades.service loaded active running Unattended Upgrades Shutdown
  …
28 loaded units listed.

Las columnas ACTIVE y SUB son las dos palabras de la línea Active de la ficha. Entre los nombres hay conocidos: snapd, del tema 36; unattended-upgrades, el de las actualizaciones automáticas del tema 35; y dos que se ocupan de los registros, de los que hablaremos en la sección 9.

$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
$ systemctl list-unit-files --type=service --state=enabled --no-pager | wc -l
52

Una lista vacía en la primera consulta es la respuesta que se quiere ver. La diferencia entre list-units y list-unit-files es la que hay entre lo que está en memoria y lo que está en el disco: un servicio instalado que nunca se inició aparece en la segunda y no en la primera.

5. Iniciar, detener, reiniciar y recargar

Las órdenes sí requieren privilegios, y siguen la costumbre de la terminal: si todo sale bien, no escriben nada. El resultado se comprueba con status.

$ sudo systemctl stop cron
$ systemctl status cron
○ cron.service - Regular background program processing daemon
     Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled; preset: enabled)
     Active: inactive (dead) since Tue 2026-10-13 11:02:40 -03; 4s ago
   Duration: 2h 33min 26s
    Process: 842 ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS (code=killed, signal=TERM)
   Main PID: 842 (code=killed, signal=TERM)
…
$ sudo systemctl start cron
$ systemctl is-active cron
active

La ficha del servicio detenido cuenta cómo terminó: systemd le envió la señal TERM, la petición cortés del tema 33, y el proceso obedeció. Si no lo hubiera hecho en noventa segundos, le habría enviado KILL. Y nótese que sigue diciendo enabled: detenerlo ahora no cambia lo que pasará en el próximo arranque.

La diferencia entre restart y reload pesa en los servicios que atienden a otros. Reiniciar un servidor web corta las conexiones en curso; recargarlo aplica la configuración nueva sin que nadie lo note. Casi todos los servicios leen su configuración una sola vez, al arrancar —la misma razón por la que hacía falta source ~/.bashrc en el tema 34—, de modo que editar un archivo de /etc no tiene efecto hasta que se hace una de las dos cosas.

Si el comando se ejecuta sin sudo, en un escritorio aparece un pedido de contraseña, y en una sesión remota, el mensaje Interactive authentication required.

Por qué no se usa kill

Un servicio es un proceso, y se le podría enviar una señal. En el tema 33 dejamos anotado qué ocurre, y ahora se puede ver:

$ pidof cron
7802
$ sudo kill -9 7802
$ pidof cron
7841
$ journalctl -u cron -n 4 --no-pager
oct 13 11:06:31 equipo systemd[1]: cron.service: Main process exited, code=killed, status=9/KILL
oct 13 11:06:31 equipo systemd[1]: cron.service: Failed with result 'signal'.
oct 13 11:06:31 equipo systemd[1]: cron.service: Scheduled restart job, restart counter is at 1.
oct 13 11:06:31 equipo systemd[1]: Started cron.service - Regular background program processing daemon.

El proceso murió y, en el mismo segundo, hay otro con otro PID. Las cuatro líneas del registro lo narran: systemd vio que el proceso principal terminó de mala manera, lo anotó como una falla y lo inició de nuevo, porque la definición del servicio se lo ordena. Es la supervisión funcionando. Para detener un servicio hay que pedírselo a quien lo vigila; enviarle señales es discutir con el supervisor.

6. enable y disable: el arranque

Hay dos preguntas independientes sobre un servicio, y cada una tiene su par de órdenes.

Las cuatro combinaciones son posibles, y todas tienen sentido:

$ sudo systemctl disable cron
…
Removed "/etc/systemd/system/multi-user.target.wants/cron.service".
$ systemctl is-enabled cron; systemctl is-active cron
disabled
active
$ sudo systemctl enable cron
…
Created symlink /etc/systemd/system/multi-user.target.wants/cron.service → /usr/lib/systemd/system/cron.service.

Deshabilitarlo no lo detuvo: son cosas separadas. Y el mensaje muestra en qué consiste, materialmente, habilitar un servicio: en crear un enlace simbólico, como los del tema 14, dentro de un directorio que systemd recorre al arrancar. multi-user.target.wants se lee «lo que el sistema quiere tener en marcha cuando llega al estado multiusuario», que es el funcionamiento normal. No hay un registro oculto: la lista de lo que arranca es un directorio de enlaces, y se puede mirar con ls.

Un servicio deshabilitado todavía puede arrancar si otro lo necesita o si alguien escribe start. Enmascararlo lo impide, y es la herramienta para cuando «deshabilité esto y sigue apareciendo».

Al instalar un paquete que trae un servicio, el comportamiento depende de la familia. En Debian y Ubuntu, apt install lo deja habilitado y funcionando. En Fedora y en Arch queda instalado y detenido, y hay que escribir enable --now. Los nombres también varían, como los de los paquetes en el tema 36:

7. Una unidad por dentro

La definición de un servicio es un archivo de texto, y systemctl cat lo muestra:

$ systemctl cat cron
# /usr/lib/systemd/system/cron.service
[Unit]
Description=Regular background program processing daemon
Documentation=man:cron(8)
After=remote-fs.target nss-user-lookup.target

[Service]
EnvironmentFile=-/etc/default/cron
ExecStart=/usr/sbin/cron -f -P $EXTRA_OPTS
IgnoreSIGPIPE=false
KillMode=process
Restart=on-failure
SyslogFacility=cron

[Install]
WantedBy=multi-user.target

Tres secciones entre corchetes, con líneas Clave=valor. Se lee sin haber visto ninguno antes:

Esto quita misterio a los servicios. Uno es un comando, más unas instrucciones sobre cuándo ejecutarlo y qué hacer si termina. Las definiciones están en dos lugares, con un reparto que ya conocemos:

Es la regla de los temas 8 y 35: /usr es del gestor de paquetes, y /etc, de quien administra la máquina. Para cambiar algo de un servicio no se toca su archivo: se escribe sudo systemctl edit servicio, que abre el editor —el de la variable EDITOR— sobre un archivo de ajustes en /etc, donde se anotan solo las líneas que cambian.

Cuando se crea o se modifica a mano un archivo de unidad, systemd no se entera hasta que se le avisa, con sudo systemctl daemon-reload. Olvidarlo produce una advertencia que conviene reconocer: Warning: The unit file changed on disk. Run 'systemctl daemon-reload' to reload units.

8. Temporizadores, apagado y servicios de usuario

Temporizadores

Un temporizador es una unidad que activa un servicio en ciertos momentos. Son la forma en que systemd programa tareas, y la razón por la que el sistema hace cosas «solo»:

$ systemctl list-timers
NEXT                        LEFT     LAST                        PASSED   UNIT                    ACTIVATES
Tue 2026-10-13 14:22:10 -03 3h 9min  Tue 2026-10-13 08:41:33 -03 2h 31min apt-daily.timer         apt-daily.service
Wed 2026-10-14 00:00:00 -03 12h      Tue 2026-10-13 08:29:14 -03 2h 43min logrotate.timer         logrotate.service
Wed 2026-10-14 06:18:44 -03 19h      Tue 2026-10-13 08:35:02 -03 2h 37min apt-daily-upgrade.timer apt-daily-upgrade.service
Mon 2026-10-19 00:33:51 -03 5 days   Mon 2026-10-12 09:01:17 -03 1 day 2h fstrim.timer            fstrim.service
…
11 timers listed.

Cada línea dice cuándo se ejecutará la próxima vez, cuánto falta, cuándo fue la última, y qué servicio dispara. Aquí está la explicación de varios comportamientos de temas anteriores. apt-daily renueva la lista de paquetes y apt-daily-upgrade instala las actualizaciones de seguridad: son los que a veces tienen ocupado el bloqueo de apt, como vimos en el tema 35. logrotate es el que archiva los registros, y aparece de nuevo en la sección 13.

Apagar y reiniciar

Como systemd administra el arranque, también administra el final. Estos comandos funcionan en un escritorio sin sudo, si no hay otros usuarios conectados:

Servicios de usuario

En el árbol de procesos del tema 32 había un segundo systemd, con la opción --user. Es una instancia propia de cada sesión, que administra servicios del usuario: el servidor de sonido, los agentes de claves, las partes del escritorio. Se la consulta con los mismos subcomandos y la opción --user, sin privilegios:

$ systemctl --user list-units --type=service --state=running | head -n 4
  UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
  dbus.service             loaded active running D-Bus User Message Bus
  pipewire.service         loaded active running PipeWire Multimedia Service
  xdg-desktop-portal.service loaded active running Portal service

Si un servicio «no existe» según systemctl status y sin embargo se lo ve en ps, puede ser de usuario: hay que repetir la consulta con --user.

9. Dos sistemas de registro

Un registro, o log, es la secuencia de mensajes que un programa va anotando sobre lo que hace: cuándo arrancó, qué pedido atendió, qué error encontró. Cada mensaje lleva la fecha, la máquina y el programa que lo escribió.

Un servicio no tiene terminal en la que escribir. Sus mensajes los recoge systemd, y en un sistema Ubuntu terminan en dos lugares a la vez, lo que al principio confunde.

El journal es binario, y esa es la excepción más notable a la regla de que en Linux todo es texto: cat sobre sus archivos muestra basura. A cambio, guarda cada mensaje con sus datos por separado —el servicio, el PID, el usuario, la gravedad— y por eso puede filtrar por cualquiera de ellos sin adivinar el formato. Y journalctl escribe texto común, de modo que todo lo aprendido en el bloque 6 se le aplica a su salida.

Los registros contienen información sensible: quién entró, desde dónde, qué comando ejecutó con sudo. Por eso no los lee cualquiera. Un usuario común ve en el journal solo sus propios mensajes; los del sistema los ven root y los miembros del grupo adm, al que pertenece el primer usuario de Ubuntu, como vimos en el tema 16. Si journalctl avisa que no muestra todo, la solución es sudo.

10. journalctl: leer el journal

Sin opciones, journalctl muestra el journal completo, desde el mensaje más antiguo que conserve, dentro de less. Son cientos de miles de líneas; casi nunca es lo que se quiere, pero sirve para ver la forma de un mensaje:

oct 13 11:02:40 equipo sudo[7790]:      ana : TTY=pts/0 ; PWD=/home/ana ; USER=root ; COMMAND=/usr/bin/systemctl stop cron
      │           │      │    │                            │
      │           │      │    │                            └─ el mensaje
      │           │      │    └─ el PID del proceso
      │           │      └─ el programa que lo escribió
      │           └─ el nombre de la máquina
      └─ la fecha y la hora

Este mensaje es, además, un recordatorio de lo dicho en el tema 19: cada uso de sudo queda anotado, con el usuario, el directorio y el comando completo.

journalctl -f es el tail -f del tema 12, aplicado al journal, y se usa de la misma manera: en una terminal se lo deja corriendo, y en otra se hace lo que se quiere observar. Es la forma de ver qué pasa en el sistema en el momento en que se conecta un dispositivo, se inicia un servicio o falla un inicio de sesión.

La opción -b delimita por arranque, que suele ser el límite natural de un problema. El journal conserva varios, y se los enumera:

$ journalctl --list-boots | tail -n 3
 -2 9c0b4e7a51f24d0c8e3a6b9d1f2c5a70 Sun 2026-10-11 09:02:11 -03 Sun 2026-10-11 23:40:02 -03
 -1 d41f8a2b6c3e49a7b5d0e1f2a3c4b5d6 Mon 2026-10-12 08:55:40 -03 Tue 2026-10-13 00:12:31 -03
  0 7a1e0c5594d34f0e8b6fa3c1d2e9b470 Tue 2026-10-13 08:29:01 -03 Tue 2026-10-13 11:20:44 -03

El índice 0 es el arranque actual, y su identificador es el Boot ID que mostraba hostnamectl en el tema 37. Los negativos son los anteriores. «¿Por qué se apagó anoche?» se responde mirando el final del arranque previo: journalctl -b -1 -e.

Cualquier usuario puede escribir en el journal, con logger. Sirve para dejar una marca antes de una prueba, y para que un script propio anote lo que hace:

$ logger -t practica "Prueba desde la terminal"
$ journalctl -t practica --no-pager
oct 13 11:21:08 equipo practica[7930]: Prueba desde la terminal

11. Filtrar: servicio, fecha y prioridad

La utilidad de journalctl está en sus filtros, que se combinan libremente. Tres cubren casi todas las consultas.

Por servicio: -u

$ journalctl -u cron -b --no-pager | tail -n 3
oct 13 11:06:31 equipo systemd[1]: cron.service: Scheduled restart job, restart counter is at 1.
oct 13 11:06:31 equipo systemd[1]: Started cron.service - Regular background program processing daemon.
oct 13 11:17:01 equipo CRON[7902]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)

-u, de unit, muestra los mensajes de un servicio: los que escribió el programa y los que escribió systemd acerca de él. Es el filtro que más se usa, y las líneas finales de systemctl status son esto mismo, limitado a diez. Se puede repetir para ver varios servicios intercalados en orden de tiempo.

Por fecha: --since y --until

$ journalctl --since "10 minutes ago" --no-pager | wc -l
37
$ journalctl -u cron --since "11:00" --until "11:10" --no-pager | wc -l
9

Las expresiones van en inglés y, si llevan espacios, entre comillas. Acotar por tiempo es lo que convierte una búsqueda imposible en una lectura de veinte líneas: si se sabe que algo falló a las tres y cuarto, se pide de las tres y diez a las tres y veinte, y se lee todo lo que ocurrió alrededor, que es donde suele estar la causa.

Por prioridad: -p

Cada mensaje lleva un nivel de gravedad, de ocho posibles. Es un dato que los archivos de texto no muestran, y que en el journal permite separar lo que importa de la rutina.

$ journalctl -b --no-pager | wc -l
4218
$ journalctl -b -p err --no-pager | wc -l
7
$ journalctl -b -p warning..warning --no-pager | wc -l
64

-p err muestra los mensajes de ese nivel y los más graves: de cuatro mil líneas quedan siete. La forma con dos puntos indica un rango, y con el mismo nivel en los dos extremos, ese nivel solo. En la pantalla, journalctl colorea las líneas según la gravedad: los errores en rojo, las advertencias en amarillo.

Conviene saber que casi todos los sistemas tienen algunos errores en cada arranque, por dispositivos que no existen o funciones que el equipo no ofrece, y que no significan nada. La manera de reconocerlos es mirar el registro cuando todo funciona bien: lo que aparece siempre no es la causa del problema de hoy.

Otros filtros y formatos

$ journalctl -t sudo --since today -o cat --no-pager | grep -c COMMAND     # usos de sudo hoy
14
$ journalctl -b -p err -o short-iso --no-pager | awk '{print $3}' | sort | uniq -c | sort -rn
      4 kernel:
      2 gdm-session-worker[2301]:
      1 bluetoothd[901]:

La segunda línea es el recuento del tema 26, aplicado a la pregunta «¿quién produce los errores?». Con --no-pager, journalctl es un productor de texto más, y encaja en cualquier tubería.

12. El registro del kernel

El kernel también escribe, y sus mensajes son los que hablan del hardware: los dispositivos que detecta, los errores de disco, la memoria que se agota. Se los lee con journalctl -k, o con el comando tradicional, dmesg, que en Ubuntu requiere sudo.

$ journalctl -k --since "2 minutes ago" --no-pager
oct 13 11:26:02 equipo kernel: usb 1-2: new high-speed USB device number 5 using xhci_hcd
oct 13 11:26:02 equipo kernel: usb 1-2: Product: DataTraveler 3.0
oct 13 11:26:03 equipo kernel: sd 2:0:0:0: [sdb] 31260672 512-byte logical blocks: (16.0 GB/14.9 GiB)
oct 13 11:26:03 equipo kernel:  sdb: sdb1
oct 13 11:26:03 equipo kernel: sd 2:0:0:0: [sdb] Attached SCSI removable disk

Es la tercera manera de saber qué nombre recibió un dispositivo, además de las dos del tema 38, y la que funciona cuando el dispositivo no aparece en lsblk: si el kernel no escribe nada al conectarlo, el problema es eléctrico; si escribe errores, ahí está el diagnóstico.

Y es aquí donde queda anotada la explicación que prometimos en el tema 37, para el programa que desaparece sin dejar mensaje:

$ journalctl -k -g 'out of memory' --no-pager
oct 12 16:41:07 equipo kernel: Out of memory: Killed process 5120 (firefox) total-vm:9812560kB, anon-rss:5234112kB, file-rss:0kB, shmem-rss:48212kB, UID:1000 pgtables:14232kB oom_score_adj:100

El kernel se quedó sin memoria y terminó el proceso 5120, que ocupaba cinco gigabytes. En los escritorios actuales suele adelantarse otro servicio, systemd-oomd, que mata antes de llegar al límite; sus mensajes se buscan con journalctl -u systemd-oomd.

Los mensajes del kernel que hay que tomar en serio son los que hablan de errores de entrada y salida en un disco —líneas con I/O error y el nombre de un dispositivo—, porque suelen anunciar un disco que está por fallar. Son la causa habitual del sistema de archivos que pasa solo a modo de solo lectura, del tema 38.

13. Los archivos de /var/log y el espacio

En Ubuntu, rsyslog sigue escribiendo los archivos de texto que recorrimos en el tema 8, y varios programas llevan además los suyos. Son los registros que se leen con las herramientas de siempre.

La penúltima fila es la razón por la que estos archivos importan aun teniendo journalctl: muchas aplicaciones escriben sus propios registros, y con más detalle que el que envían al sistema. El proyecto del tema 42 consiste en analizar uno de ellos.

$ ls -lh /var/log/syslog*
-rw-r----- 1 syslog adm 2,1M oct 13 11:26 /var/log/syslog
-rw-r----- 1 syslog adm 5,8M oct 12 00:00 /var/log/syslog.1
-rw-r----- 1 syslog adm 612K oct  5 00:00 /var/log/syslog.2.gz
-rw-r----- 1 syslog adm 588K sep 28 00:00 /var/log/syslog.3.gz
-rw-r----- 1 syslog adm 640K sep 21 00:00 /var/log/syslog.4.gz
$ grep -c 'cron' /var/log/syslog
31
$ zgrep -c 'cron' /var/log/syslog.2.gz
214

Los permisos confirman lo dicho: rw-r-----, del usuario syslog y el grupo adm. Y la lista muestra la rotación.

La rotación de registros es el procedimiento por el cual, periódicamente, el archivo en uso se renombra, se empieza uno nuevo, se comprimen los anteriores y se borra el más viejo. Evita que un registro crezca sin límite.

La hace logrotate, activado cada noche por el temporizador de la sección 8, según las reglas de /etc/logrotate.d/. El archivo sin número es el actual; el .1, el período anterior, todavía sin comprimir; del .2.gz en adelante, los más viejos, que se leen sin descomprimir con zcat, zless y zgrep, del tema 15. Un servidor que conserva cuatro semanas responde por lo ocurrido en el último mes, y no más.

El espacio del journal

El journal se limita solo, a una fracción del sistema de archivos, pero esa fracción puede ser de gigabytes. Es la parte que le tocaba a este tema del inventario de la sección 8 del tema 38:

$ journalctl --disk-usage
Archived and active journals take up 1.1G in the file system.
$ sudo journalctl --vacuum-size=200M
…
Vacuuming done, freed 904.0M of archived journals from /var/log/journal/3f9c41d27a8e4b6b9d0e5a17c2f48b61.

El directorio lleva por nombre el Machine ID del tema 37. Para que el límite sea permanente se fija SystemMaxUse=200M en /etc/systemd/journald.conf, y se reinicia systemd-journald. Como siempre, lo que es de un programa se limpia con ese programa, no con rm.

14. Diagnosticar un servicio que falla

Las dos mitades del tema se juntan en una situación: se cambió la configuración de un servicio, se lo reinició, y no arranca. El ejemplo es el servidor de acceso remoto, ssh, del que nos ocupamos en el tema siguiente.

$ sudo systemctl restart ssh
Job for ssh.service failed because the control process exited with error code.
See "systemctl status ssh.service" and "journalctl -xeu ssh.service" for details.
$ systemctl status ssh --no-pager -n 0
× ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Tue 2026-10-13 11:34:09 -03; 6s ago
    Process: 8123 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255/EXCEPTION)
        CPU: 12ms
$ journalctl -u ssh -b -n 4 --no-pager
oct 13 11:34:09 equipo sshd[8123]: /etc/ssh/sshd_config: line 34: Bad configuration option: PermitRootLogn
oct 13 11:34:09 equipo sshd[8123]: /etc/ssh/sshd_config: terminating, 1 bad configuration options
oct 13 11:34:09 equipo systemd[1]: ssh.service: Control process exited, code=exited, status=255/EXCEPTION
oct 13 11:34:09 equipo systemd[1]: ssh.service: Failed with result 'exit-code'.

El mensaje de error de systemctl no dice qué pasó, pero dice dónde mirar, con los dos comandos escritos. La ficha confirma el estado failed y muestra que el proceso terminó con un código de salida distinto de cero. Y el registro tiene la respuesta completa, en la primera línea: archivo, número de línea y la palabra mal escrita. Falta una letra en PermitRootLogin.

1. Leer el estado: systemctl status servicio. ¿failed, o inactive? ¿Con qué código terminó? qué
2. Leer el registro: journalctl -u servicio -b -e. Buscar el primer error, no el último. por qué
3. Corregir la causa: casi siempre, una línea de un archivo de /etc. arreglar
4. Probar la configuración sin reiniciar, si el servicio lo permite. arreglar
5. Reiniciar y comprobar: sudo systemctl restart servicio, y otra vez status. verificar

El segundo paso tiene su indicación: el primer error. Cuando un programa falla, el motivo real se escribe una vez, y después vienen las consecuencias, que son las líneas que quedan a la vista al final. En el ejemplo, las dos últimas son de systemd constatando el fracaso; la causa estaba dos líneas más arriba.

El cuarto paso evita repetir el accidente. Muchos servicios tienen una opción que revisa la configuración y termina, sin afectar al que está funcionando. Es el mismo principio que mount -a para fstab, en el tema 38: probar antes de comprometerse.

15. Recetas y errores comunes

La referencia del tema:

Con este tema el equipo ya no tiene partes opacas: sabemos qué programas tiene instalados, qué recursos consume, qué servicios lo mantienen andando y dónde escribe cada uno lo que le pasa. Hasta aquí, todo ocurrió dentro de una sola máquina. El último tema del bloque sale de ella. En el tema 40 vemos la red desde la terminal: averiguar la propia dirección, comprobar si otro equipo responde, descargar un archivo, y entrar a una máquina remota con ssh para usar allí todo lo aprendido.

16. Resumen

• Un servicio es un programa que funciona en segundo plano de manera permanente. systemd, el proceso de PID 1, los inicia, los supervisa y recoge sus mensajes. Cada cosa que administra es una unidad.
• systemctl status servicio muestra si funciona, desde cuándo, con qué procesos y qué fue lo último que escribió. No requiere sudo.
• active (running) es el estado normal; inactive, detenido; failed, que quiso funcionar y no pudo.
• systemctl --failed lista lo que falló, y list-units --type=service --state=running, lo que está en ejecución.
• start, stop y restart actúan ahora. reload hace releer la configuración sin detener el servicio. Un cambio de configuración no rige hasta reiniciar o recargar.
• Un servicio no se detiene con kill: systemd lo relanza. Se le pide a systemctl.
• enable y disable deciden si arranca con el sistema, y son independientes de si funciona ahora. enable --now hace las dos cosas.
• La definición de un servicio es un archivo de texto: systemctl cat lo muestra. Los de los paquetes están en /usr/lib/systemd/system, y los cambios locales, en /etc/systemd/system.
• Los temporizadores activan servicios a ciertas horas: systemctl list-timers.
• Los mensajes van al journal, binario, que se lee con journalctl, y en Debian y Ubuntu también a archivos de texto en /var/log.
• journalctl -u servicio filtra por servicio; -b, por arranque; --since y --until, por fecha; -p err, por gravedad. -f sigue los mensajes en vivo.
• journalctl -k y dmesg muestran el registro del kernel: dispositivos, errores de disco y procesos terminados por falta de memoria.
• Los archivos de /var/log se rotan: el actual, el .1 y los .gz, que se leen con zgrep. Un registro en uso se vacía, no se borra.
• journalctl --vacuum-size reduce el espacio del journal.
• Un servicio que falla se diagnostica con status y journalctl -u, buscando el primer error; se corrige, se prueba la configuración y se reinicia.

17. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Ejecuta systemctl status cron, o crond en tu distribución. Identifica el archivo de unidad, si está habilitado, desde cuándo funciona, su PID y cuánta memoria ocupa. Compara el PID con el de pidof.
2. Cuenta los servicios en ejecución, los habilitados y los instalados. Comprueba con systemctl --failed que no haya ninguno fallado, o averigua por qué lo está.
3. Detén cron, mira su ficha, e inícialo de nuevo. Encadena systemctl is-active --quiet cron con && y || para que escriba «funciona» o «detenido», y pruébalo en los dos estados.
4. Con cron en marcha, anota su PID, mátalo con sudo kill -9, y vuelve a mirar el PID. Lee con journalctl -u cron -n 6 cómo lo contó systemd.
5. Deshabilita cron y comprueba que sigue activo. Lista el directorio /etc/systemd/system/multi-user.target.wants/ antes y después de volver a habilitarlo.
6. Muestra el archivo de unidad de tres servicios con systemctl cat. En cada uno, ubica el comando que lo inicia y su política de reinicio.
7. Ejecuta systemctl list-timers. ¿Cuál es el próximo en ejecutarse? Averigua con systemctl cat qué comando lanzará.
8. Abre journalctl -f en una terminal. Desde otra, ejecuta logger -t practica "hola", un comando con sudo, y conecta un dispositivo USB si tienes. Observa qué aparece en cada caso.
9. Cuenta los mensajes del arranque actual, y cuántos son de nivel warning y cuántos err. Obtén la lista de los programas que más errores produjeron, con awk, sort y uniq -c.
10. Consulta cuánto ocupa el journal, y cuántos arranques conserva. Lista /var/log/syslog*, si existen, y busca la palabra error, sin distinguir mayúsculas, en el archivo actual y en uno comprimido.