# Diagnóstico de problemas con systemd, journalctl y strace

**Categoría:** Linux y sistemas · **Nivel:** Intermedio · **Lectura:** 11 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/linux/diagnostico-con-systemd-journalctl-y-strace/

## Respuesta rápida

Diagnosticar un problema en Linux es preguntar **en orden**, de lo general a lo específico. Primero, el **estado** del servicio: `systemctl status <servicio>` dice si está activo, desde cuándo y muestra las últimas líneas de registro. Segundo, los **registros**: `journalctl` es el registro unificado de todo el sistema, y se acota con `-u` (un servicio concreto), `-b` (el arranque actual), `-p` (por prioridad, para ver solo errores), `--since` (desde una fecha) y `-f` (seguir en vivo). Con eso se resuelve la enorme mayoría de los casos. Tercero, y solo cuando el registro no alcanza, **`strace`** muestra qué llamadas al sistema hace un proceso —qué archivo intenta abrir, qué conexión falla—, útil para el clásico «falla y no dice por qué». La regla: **estado, después registros, y strace solo como último recurso**.

## El método: preguntar en orden

El error que hace perder horas es empezar por la herramienta más potente. El método correcto es el contrario: **de lo general a lo específico**, bajando de nivel solo cuando el anterior no respondió.

> **Los tres niveles**
>
> **1. Estado** — ¿el servicio está corriendo? `systemctl status` lo dice y muestra las últimas líneas de registro. Muchas veces alcanza. **2. Registros** — ¿qué dijo cuando falló? `journalctl` tiene el historial completo. Resuelve la mayoría de lo que el estado no aclara. **3. Llamadas al sistema** — ¿qué le pide el proceso al núcleo? `strace`, solo cuando el registro no explica el fallo.

## El estado del servicio

La primera pregunta ante cualquier «no anda» de un servicio. El comando de estado condensa muchísima información útil en una pantalla:

```bash
# El estado de un servicio: activo o fallido, desde cuándo, y últimas líneas.
systemctl status nginx
```

Qué mirar en esa salida, en orden de importancia:

- **La línea `Active:`.** Dice `active (running)` si anda, o `failed` si falló. Si falló, suele venir con un código de salida que ya orienta.
- **Las últimas líneas de registro.** El estado incluye las últimas líneas que el servicio escribió, y con muchísima frecuencia el error está ahí mismo: un archivo que no encuentra, un puerto ocupado, un permiso denegado.
- **Si está habilitado.** Indica si arrancará solo al reiniciar. Un servicio activo pero no habilitado es la causa del clásico «funcionaba hasta que reinicié».

En una parte importante de los casos, el diagnóstico termina acá: esas últimas líneas ya nombran la causa. Cuando no, se baja al nivel siguiente.

## journalctl: el registro unificado

En los sistemas con systemd, **journalctl** es el registro central: guarda los mensajes de todos los servicios y del núcleo en un solo lugar, con marca de tiempo. Sin filtros vuelca todo, que es abrumador; su valor está en acotarlo.

```bash
# Todo el registro, paginado. Sin filtros es demasiado: casi nunca se usa así.
journalctl

# Lo más útil: el registro de UN servicio concreto.
journalctl -u nginx

# Los mensajes del arranque ACTUAL. -b 0 es este arranque; -b -1 el anterior.
journalctl -b

# Seguir en vivo: dejar corriendo y reproducir el problema en otra terminal.
journalctl -u nginx -f
```

De todas, la opción `-u` es la que más se usa: casi siempre sabés qué servicio te preocupa, y ver *solo* sus mensajes convierte un muro de texto en algo legible. Y `-f`, seguir en vivo, es el patrón para problemas que se reproducen: se deja el registro corriendo y se provoca el fallo mirando qué aparece en el momento exacto.

## Filtrar los registros

Cuando el servicio y el arranque no alcanzan para acotar, se filtra por **prioridad** y por **tiempo**. Son las dos dimensiones que convierten «hay demasiado» en «acá está»:

```bash
# Solo errores y peor: -p err descarta el ruido informativo.
journalctl -p err -b

# Por rango de tiempo. Acepta fechas y expresiones como "1 hour ago".
journalctl --since "2026-07-28 09:00" --until "2026-07-28 10:00"
journalctl --since "1 hour ago"

# Combinado: errores de un servicio en la última hora, con explicación (-x).
journalctl -u nginx -p err --since "1 hour ago" -x

# Solo mensajes del núcleo (hardware, controladores).
journalctl -k
```

Dos opciones que ayudan a leer: `-x` agrega, cuando existe, una explicación más larga del mensaje; y `-r` muestra lo más reciente primero, cómodo cuando solo te interesa lo último que pasó. El patrón que resuelve casi todo es combinar servicio, prioridad y tiempo: «errores de *este* servicio en *este* rato».

> **Atención**
>
> El registro tiene un tamaño limitado y va descartando lo viejo, así que un problema de hace semanas puede haber desaparecido. `journalctl --disk-usage` muestra cuánto ocupa, y en un servidor conviene revisar que la retención sea suficiente para el ritmo al que se investigan los problemas.

## strace: el último recurso

A veces un programa falla y *no dice por qué*: ni el estado ni el registro explican nada. Ahí entra **strace**, que muestra cada **llamada al sistema** que hace un proceso: cada archivo que intenta abrir, cada conexión que intenta, cada permiso que pide. Es ver la conversación entre el programa y el núcleo.

```bash
# Rastrear un comando desde su inicio.
strace ./programa

# Lo más útil en la práctica: filtrar por tipo de llamada.
# Solo aperturas de archivo: revela qué archivo busca y no encuentra.
strace -e trace=open,openat ./programa

# Rastrear un proceso que YA está corriendo, por su número.
sudo strace -p 4521

# Guardar la salida a un archivo para leerla con calma.
strace -o traza.txt ./programa
```

El caso donde strace brilla es el **«no encuentra algo y no dice qué»**: filtrando las aperturas de archivo se ve exactamente qué ruta intenta abrir el programa antes de fallar, y muchas veces es un archivo de configuración en un lugar inesperado o un permiso mal puesto. Dicho esto, es una herramienta ruidosa —genera muchísima salida— y por eso es el *último* nivel: se llega cuando el registro no alcanzó, no antes.

## Un caso completo

El método se ve mejor con un caso típico: el servidor web no arranca tras un cambio de configuración.

1. **Estado** `systemctl status nginx` muestra `failed` y, en las últimas líneas, algo como «no se pudo enlazar al puerto 80». Ya hay una pista fuerte.
2. **Registro del servicio** `journalctl -u nginx -p err --since "10 min ago"` confirma el error y da el detalle: el puerto 80 está en uso por otro proceso.
3. **Quién ocupa el puerto** Con las herramientas de red se identifica el proceso que ya tiene el puerto tomado. Diagnóstico resuelto sin llegar a strace.
4. **Si el error hubiera sido opaco** Si el registro solo dijera «no pude iniciar» sin motivo, `strace` sobre el arranque mostraría qué archivo o recurso falla, cerrando el caso.

> Este método es la contracara de [administrar un servidor](../administracion-de-servidores-linux-desde-cero/index.md): la administración pone los servicios en marcha, y el diagnóstico los recupera cuando fallan. Y es especialmente útil tras [una actualización](../actualizar-el-sistema-operativo-linux/index.md), cuando algo que andaba deja de andar y el registro dice exactamente qué cambió.

## Errores frecuentes

- **Empezar por strace.** Es el último nivel, no el primero: genera tanto ruido que esconde lo que el estado te habría dicho enseguida.
- **No leer las últimas líneas del estado.** Con mucha frecuencia el error está ahí, en la salida de `systemctl status`.
- **Volcar journalctl sin filtros.** Es un muro de texto. Acotá por servicio, prioridad y tiempo.
- **Ignorar la prioridad.** `-p err` descarta el ruido informativo y deja lo que importa.
- **Olvidar que el registro se descarta.** Un problema viejo puede haberse ido; revisá la retención en servidores.
- **No usar `-f` para problemas reproducibles.** Seguir en vivo mientras se provoca el fallo muestra el momento exacto.
- **Confundir «activo» con «habilitado».** Un servicio activo sin habilitar no vuelve tras reiniciar.

## Preguntas frecuentes

**¿Por dónde empiezo cuando algo no anda?**
Por lo más general, no por lo más potente. El primer paso ante un servicio que falla es mirar su estado con el comando de estado de systemctl, porque en una sola pantalla dice si está activo o falló, desde cuándo, con qué código, e incluye las últimas líneas que el servicio escribió, donde muy a menudo está la causa. Si eso no alcanza, el segundo paso es el registro con journalctl, acotado al servicio que te preocupa. Y solo si el registro tampoco explica el fallo se recurre a strace. Ese orden —estado, registros, llamadas al sistema— es lo que separa resolver un problema en minutos de pelearse con él durante horas.

**¿Qué es journalctl y en qué se diferencia de los archivos de registro?**
journalctl es la herramienta para consultar el registro de systemd, que es un registro unificado y estructurado donde se guardan los mensajes de todos los servicios y del núcleo con marca de tiempo y metadatos. La diferencia con los archivos de registro de texto tradicionales es que no tenés que saber en qué archivo escribe cada servicio ni combinar varios a mano: consultás un único registro y lo filtrás por servicio, por arranque, por prioridad o por rango de tiempo. Eso hace que correlacionar lo que pasó en distintos servicios en el mismo momento sea directo, algo bastante engorroso cuando cada uno escribe en su propio archivo suelto.

**¿Cómo veo solo los errores y no todo el registro?**
Con el filtro de prioridad. Los mensajes del registro tienen niveles de severidad, y pedir a partir del nivel de error hacia arriba descarta todo el ruido informativo y de depuración, dejando solo lo que probablemente sea el problema. Ese filtro se combina con los demás para acotar aún más: podés pedir los errores de un servicio concreto, en el arranque actual, dentro de la última hora. Esa combinación —servicio, prioridad y tiempo— es la que convierte un registro de miles de líneas en las pocas que te interesan, y es el patrón que resuelve la enorme mayoría de los diagnósticos sin necesidad de herramientas más pesadas.

**¿Para qué sirve strace exactamente?**
strace muestra las llamadas al sistema que hace un proceso, es decir, todo lo que el programa le pide al núcleo: abrir archivos, leer o escribir, conectarse a la red, pedir memoria. Sirve cuando un programa falla sin dar un mensaje útil, porque te deja ver qué intentaba hacer justo antes de fallar. El caso clásico es el de un programa que no encuentra algo pero no dice qué: filtrando las llamadas de apertura de archivo se ve exactamente qué ruta intenta abrir y no existe, o qué permiso le falta. Es muy potente, pero también muy ruidosa, así que es una herramienta de último recurso, cuando el estado y los registros no bastaron.

**¿Por qué no aparecen registros viejos?**
Porque el registro tiene un tamaño máximo y va descartando automáticamente lo más antiguo para no llenar el disco. Eso significa que un problema ocurrido hace semanas puede haberse borrado ya, sobre todo en un sistema con mucha actividad que genera muchos mensajes. Podés consultar cuánto espacio ocupa el registro actualmente, y en un servidor conviene revisar que la política de retención guarde suficiente historial para el ritmo al que investigás los problemas: si sueles enterarte de las cosas con varios días de retraso, necesitás que el registro conserve al menos ese período. La configuración de cuánto se retiene es ajustable según cuánta historia necesites y cuánto disco quieras dedicarle.

**¿Esto sirve en cualquier distribución?**
El método de preguntar en orden —estado, registros, llamadas al sistema— sirve en cualquier sistema. Las herramientas concretas dependen del sistema de inicialización: systemctl y journalctl son de systemd, que es lo que usan hoy las distribuciones principales como Ubuntu, Debian, Fedora y la mayoría, así que en ellas los comandos de esta guía funcionan tal cual. En las pocas distribuciones que no usan systemd, los registros están en archivos de texto que se leen con las herramientas generales de la terminal, y la gestión de servicios se hace con otro sistema, pero la lógica de diagnóstico es idéntica. strace, por su parte, funciona en cualquier sistema Linux con independencia del sistema de inicialización.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Consultas de la comunidad del tipo «no me arranca el servicio» y cómo se resuelven leyendo los registros.
2. **Underc0de, foro.** [Sección Scripting](https://underc0de.org/foro/scripting/). Depuración de procesos y automatización.

### Documentación oficial

1. **systemd.** [journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html). La referencia oficial de las opciones de consulta de registros citadas en la guía.
2. **systemd.** [systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html). La gestión y el estado de los servicios.
3. **strace.** [strace](https://strace.io/). La herramienta de rastreo de llamadas al sistema.
4. **systemd.** [systemd](https://systemd.io/). El proyecto que integra el sistema de arranque, los servicios y el registro.
5. **The Linux man-pages project.** [man-pages](https://www.kernel.org/doc/man-pages/). Las páginas de manual de cada herramienta en el propio sistema.

## Guías relacionadas

- [Administrar servidores Linux](../administracion-de-servidores-linux-desde-cero/index.md)
- [Comandos útiles de Linux](../comandos-utiles-de-linux/index.md)
- [Configurar un servidor web](../configurar-un-servidor-web-en-linux/index.md)
- [Actualizar el sistema](../actualizar-el-sistema-operativo-linux/index.md)
- [Índice de Linux y sistemas](../index.md)