Solucionar el error failed to start Apport crash report service

El error failed to start Apport crash report service indica que el sistema de gestión de informes de errores de Ubuntu no puede iniciarse correctamente durante la secuencia de arranque. La solución más efectiva, si no necesitas enviar reportes de depuración a Canonical, es desactivar el servicio por completo para eliminar el bloqueo en el inicio.

Qué significa el error

Este error aparece en la consola o durante el proceso de arranque (boot) en distribuciones basadas en Debian y Ubuntu. El servicio Apport es el encargado de capturar y generar informes cuando una aplicación falla o se cierra inesperadamente. Cuando el demonio apport.service falla, puede causar tiempos de espera (timeouts) en el gestor de servicios systemd, retrasando o impidiendo que el sistema operativo cargue el entorno de escritorio. Afecta principalmente a usuarios que han experimentado cierres forzados frecuentes o instalaciones donde la base de datos de errores está corrupta.

Causas más habituales

• Corrupción en los archivos de configuración dentro de /etc/default/apport.
• Base de datos de informes de fallos (en /var/crash) demasiado grande o con permisos incorrectos.
• Conflictos entre la versión actual de Apport y actualizaciones recientes del kernel.
• Fallo en la comunicación con el servicio de reporte automático de Canonical.
• Permisos incorrectos o bloqueos de acceso en el directorio del sistema /var/crash.
• Incompatibilidades con controladores de vídeo propietarios o módulos del kernel de terceros.

Antes de empezar

Para ejecutar estos comandos, necesitas acceso root o privilegios de superusuario (sudo). Asegúrate de tener una terminal accesible; si el sistema no arranca, inicia en modo recuperación (Recovery Mode) desde el menú de GRUB. No es necesario realizar copias de seguridad de datos personales, ya que estas operaciones solo afectan a archivos temporales de sistema, pero siempre es recomendable tener un backup de tus documentos importantes ante cualquier manipulación del sistema.

Solución 1: Desactivar Apport permanentemente

Esta es la opción más recomendada si el servicio causa bloqueos constantes en el arranque. Al desactivarlo, el sistema dejará de intentar generar informes de errores, lo cual no afecta al rendimiento ni a la estabilidad del software.

1. Abre el archivo de configuración de Apport con un editor de texto en consola: sudo nano /etc/default/apport.
2. Busca la línea que contiene el parámetro enabled=1.
3. Modifica dicho parámetro cambiando el valor a enabled=0.
4. Guarda los cambios presionando Ctrl + O, confirma con Enter y sal del editor con Ctrl + X.
5. Detén el servicio inmediatamente en la sesión actual ejecutando: sudo systemctl stop apport.
6. Desactiva el arranque automático del servicio mediante systemd: sudo systemctl disable apport.service.

Al modificar este archivo y deshabilitar el servicio en systemd, le indicas al demonio de inicio que ignore por completo este componente, evitando que el gestor systemd pierda tiempo intentando arrancarlo y genere tiempos de espera prolongados durante el inicio del sistema.

Solución 2: Limpiar los informes de errores antiguos y corregir permisos

A veces, el servicio falla simplemente porque el directorio /var/crash está lleno de reportes antiguos o contiene permisos corruptos que impiden la escritura de nuevos logs, provocando un error de entrada/salida (I/O) al arrancar.

1. Accede a la terminal y navega hasta el directorio donde se almacenan los logs de fallos: cd /var/crash.
2. Verifica el contenido de la carpeta y los permisos asociados: ls -l.
3. Elimina los archivos acumulados de forma segura: sudo rm -f /var/crash/*.
4. Restablece los permisos correctos de la carpeta del sistema con los comandos: sudo chown root:whoopsie /var/crash y sudo chmod 1777 /var/crash.
5. Reinicia el servicio para comprobar si inicia correctamente: sudo systemctl restart apport.

Este procedimiento libera espacio crítico en disco, elimina archivos corruptos que el servicio intenta procesar en bucle durante el arranque y restituye los permisos sticky bit necesarios para que el usuario del sistema pueda gestionar los reportes sin bloquear el demonio.

Solución 3: Reinstalar el paquete Apport y sus dependencias

Si los archivos binarios del servicio o las ejecuciones de Python asociadas están dañados, la configuración manual no será suficiente. Reinstalar el paquete asegura que todos los scripts de inicio, ejecutables y dependencias vuelvan a su estado original.

1. Actualiza los índices de los repositorios de tu sistema: sudo apt update.
2. Purga por completo la configuración previa y el paquete ejecutando: sudo apt purge apport apport-gtk.
3. Vuelve a instalar el servicio y su interfaz de usuario: sudo apt install apport apport-gtk.
4. Limpia posibles paquetes huérfanos residuales: sudo apt autoremove.
5. Reinicia el equipo para aplicar las correcciones: sudo reboot.

La reinstalación limpia sobrescribe cualquier archivo ejecutable dañado en el sistema que pueda estar desencadenando excepciones imprevistas en Python durante el proceso de ejecución de systemd.

Solución 4: Ajustar la configuración de Whoopsie

Apport trabaja conjuntamente con Whoopsie, el demonio encargado de enviar los informes de fallos a los servidores de Canonical. Si Whoopsie tiene problemas de conectividad o su configuración está desincronizada, provocará que Apport falle en cadena.

1. Abre el servicio Whoopsie para verificar su estado actual: systemctl status whoopsie.
2. Si el servicio muestra errores, deténlo mediante: sudo systemctl stop whoopsie.
3. Revisa o crea la carpeta de estado necesaria ejecutando: sudo mkdir -p /var/lib/whoopsie.
4. Asegura la propiedad del directorio para el usuario adecuado: sudo chown whoopsie:whoopsie /var/lib/whoopsie.
5. Reinicia ambos servicios para verificar la sincronización: sudo systemctl restart whoopsie apport.

Restablecer la estructura de directorios de Whoopsie evita que Apport se quede bloqueado al intentar comunicar el informe de fallos a una pila de transporte inaccesible.

Solución 5: Revisar conflictos con Systemd y enmascarar el servicio

Si el error persiste tras la reinstalación, es posible que otros servicios o unidades de inicio estén bloqueando la ejecución. Puedes consultar nuestra guía sobre cómo diagnosticar y solucionar el error Systemd Failed to Start en Linux para identificar si hay un problema más profundo en la cadena de arranque.

1. Ejecuta el comando para ver los fallos recientes del demonio: systemctl status apport.service.
2. Examina los registros de depuración detallados con: journalctl -u apport.service -b.
3. Si aparece el error Dependency failed o persiste la falla de inicio, procede a enmascarar el servicio: sudo systemctl mask apport.service.

Enmascarar el servicio crea un enlace simbólico hacia /dev/null, siendo una medida más drástica que desactivarlo, ya que impide de manera absoluta que cualquier otro proceso, usuario o dependencia del sistema pueda invocarlo inadvertidamente.

Cómo comprobar que se ha solucionado

Tras aplicar cualquiera de los métodos expuestos, debes reiniciar el equipo para evaluar el arranque. Una vez en el entorno de escritorio o consola, ejecuta el comando para verificar el estado: systemctl status apport.

• Si lo has desactivado o enmascarado: El estado debe indicar claramente Loaded: loaded (/lib/systemd/system/apport.service; disabled) o Loaded: masked (/dev/null; masked) con una marca de Active: inactive (dead).
• Si lo has reparado o reinstalado: El estado mostrará Active: active (running) o Active: inactive (dead) en color verde, indicando que el servicio cargó sin devolver ningún código de error en rojo.
• Comprobación de logs de arranque: Ejecuta journalctl -b | grep -i apport. Si el problema está resuelto, no verás ninguna línea roja que contenga Failed to start Apport crash report service.

Si nada de lo anterior funciona

Si el sistema sigue mostrando errores en el arranque, revisa los logs detallados del kernel mediante journalctl -b -p err. Esto te mostrará todos los errores críticos ocurridos durante el último arranque. Si el error persiste y el sistema es inestable, es posible que exista un problema con el sistema de archivos (corrupción en el disco) o con el kernel instalado. Consulta la documentación oficial de Ubuntu para verificar si tu versión del kernel tiene problemas conocidos con Apport. Si el error impide el acceso al sistema, considera arrancar desde un Live USB para realizar una comprobación de disco con fsck.

Preguntas frecuentes

¿Desactivar Apport afecta a la seguridad del sistema?

No, Apport solo se encarga de recopilar información sobre fallos de software para enviarla a los desarrolladores. Desactivarlo no compromete la seguridad ni la integridad de tu sistema, solo evita que se generen informes automáticos cuando una aplicación se cierra de forma inesperada.

¿Es normal que /var/crash tenga archivos pesados?

Sí, es normal en sistemas que han sufrido bloqueos frecuentes. Estos archivos son volcados de memoria (core dumps) que pueden ocupar varios gigabytes. Si tu disco está lleno, borrar estos archivos es una tarea de mantenimiento necesaria para recuperar espacio y estabilidad.

¿Debo reinstalar Ubuntu si Apport sigue fallando?

No es necesario reinstalar el sistema operativo por un fallo en Apport. Este es un componente secundario. Si el sistema arranca y funciona correctamente, puedes ignorar el error o mantener el servicio desactivado permanentemente sin riesgo alguno para tus datos o aplicaciones.

¿Cómo sé si el error es de hardware?

Si además del error de Apport experimentas bloqueos aleatorios, reinicios espontáneos o errores de lectura/escritura en otras aplicaciones, es probable que haya un fallo en el disco duro o en la memoria RAM. En ese caso, Apport solo está reportando el síntoma de un problema físico subyacente.

¿Puedo volver a activar Apport en el futuro si lo necesito?

Sí, de manera muy sencilla. Si lo desactivaste en el archivo de configuración, basta con editar de nuevo /etc/default/apport cambiando la opción a enabled=1 y ejecutando sudo systemctl enable --now apport. Si habías enmascarado la unidad con systemd, primero debes usar sudo systemctl unmask apport.service.

¿Por qué Apport genera fallos recurrentes justo después de actualizar el kernel?

Cuando se actualiza el kernel de Linux, algunos módulos de terceros o controladores de hardware antiguos pueden perder la compatibilidad momentáneamente. Al fallar el arranque de esos módulos en la fase inicial, Apport intenta capturar múltiples fallos a la vez de forma prematura, colapsando su propio servicio antes de que los subsistemas del sistema operativo estén completamente listos.