errores

  • Este breve artículo explica cómo listar las tareas de backup en estado de error desde línea de comandos en Bacula.

  • Este artículo explica cómo capturar excepciones (errores no programáticos, de tiempo de ejecución) en Python, y cuáles son los tipos de excepciones disponibles.

  • Hace unos meses expliqué cómo deshabilitar el reporte de errores en Ubuntu: Qué es "whoopsie" y cómo eliminarlo. Esta vez es el turno de CentOS.

  • Los sistemas de archivos ext2, ext3 y ext4 poseen varios parámetros configurables, entre los que se destaca la verificación periódica de errores. Esto es, cada vez que el kernel Linux intenta montar un sistema de archivos, debe comprobar antes si es momento para ejecutar una verificación periódica de errores. Esta verificación puede ser cada cierto número de montajes, cada cierto período de tiempo, o ambas.

  • Esta fue una semana de respuestas HTTP un tanto insólitas para mí. Luego de haber comentado mi experiencia diagnosticando una respuesta HTTP 503, esta vez me tocó solucionar el caso de una respuesta HTTP 413 en un servidor Nginx:

  • Una pregunta de un lector en las redes sociales me impulsó a investigar cómo es posible verificar el estado de salud de un disco rígido en GNU/Linux. Siempre pienso que el día en que me alcance la muerte seguiré siendo un usuario novato de GNU/Linux. Todos los días hay conocimientos nuevos por adquirir, y cada vez que aprendo algo nuevo me doy cuenta que ignoro 10 cosas más que no conocía. Así que cada día en GNU/Linux siento que soy más y más ignorante :S

    Cómo muchos sabrán, los discos rígidos (desde los primeros ATA) poseen la tecnología S.M.A.R.T. (Self Monitoring Analysis and Reporting Technology) capaz de autodetectar fallos de disco a nivel físico. La detección temprana de daños en la superficie del disco, permite poder realizar una copia de seguridad y reemplazarlo, antes de que se produzca una pérdida de datos irrecuperable.

  • Muchas veces suele ocurrir que errores de programación de PHP (por ejemplo, falta de validación de variables o comprobación de límites en estructuras) llenan los logs del servidor Apache con mensajes PHP Notice. Si estos errores se repiten muy frecuentemente, pueden ocasionar un problema de espacio en disco (ya que los archivos de log crecen en forma desmedida). Sin contar con que llenan los logs con mensajes irrelevantes para el administrador de sistemas. Por lo tanto, puede ser necesario deshabilitarlos para que directamente no se guarde registro de los mismos en los logs de Apache.

  • Esta semana descubrí una herramienta interesante que nos puede ayudar a diagnosticar errores y problemas con certificados y verificar conexiones SSL/TLS, desde un navegador Web, llamada SSL Checker.

  • En este breve artículo comparto una experiencia con un servidor Apache retornando "503 Service Unavailable":

  • Al hacer debugging de scripts PHP es posible que necesitemos enviar mensajes de error a Apache si las tradicionales "banderitas" no funcionan. Puede ser el caso en el que un script entre en un bucle infinito y no alcance a mostrar por salida estándard sentencias "echo" o "print" (a pesar de que estén antes de la ejecución del bucle o ejecución problemática)

  • Mientras realizaba unas tareas de reconfiguración de un servidor Web Apache, me topé con los siguientes errores al momento de reiniciar el servicio:

    Address already in use: make_sock: could not bind to address
    

    Este error indica que el socket está en uso, es decir, no se puede ligar al puerto 80 en la dirección especificada porque está ocupado por otro proceso.

    Unable to open logs
    Action 'start' failed.
    

    Y este error indica que no puede abrir los archivos de log, por la misma razón.

  • No voy a hacer un juicio de valor sobre cada uno de éstos bugs, simplemente los comparto y saquen sus propias conclusiones. Mentira, voy a hacer un juicio de valor porque son errores bizarros, delirantes y algunos espeluznantes. Se aceptan comentarios.

  • Al iniciar un servidor Web que da soporte a una plataforma Moodle me encontré con el siguiente error:

    Coding error detected, it must be fixed by a programmer: Failed to unserialise data from file. Either failed to read, or failed to write.
    
  • Luego de haber resuelto el error "Coding error detected, it must be fixed by a programmer" me topé con el siguiente:

    File store path does not exist and can not be created
  • Cuando se necesita hacer debug de aplicaciones Web y no se tiene acceso a los logs del servidor Web (por ejemplo porque se trata de un Web server gratuito, con muchas limitaciones en cuanto a herramientas de administración) es posible mostrar los errores de PHP directamente en el código HTML de salida.

  • La semana pasada la persona responsable de la administración de la plataforma Moodle de nuestra institución me comentó que estaban teniendo problemas con el envío de mails de notificaciones de los foros. Simplemente ni estaba llegando ninguna notificación de novedades en los foros. Pero lo más extraño era que el resto del envío de mails de Moodle (por ejemplo recupero de contraseñas de usuarios) sí estaban funcionando, lo cual descartaba cualquier tipo de problema con el servidor de correo.

  • Luego de haber instalado una aplicación PHP, uno de los scripts comenzó a arrojar este error en el log del servidor Web al momento de verificar su funcionamiento.

  • Desde que instalé logwatch en uno de mis viejos servidores Fedora Core 4 veo el siguiente error en el reporte, en la sección del kernel:

     ---------------------- Kernel Begin -------------------------
    
    
    egrep: module: No such file or directory
    
    
     ---------------------- Kernel End -------------------------
    
  • En GNU/Linux, el programa cron es un demonio (o "servicio", como prefieran llamarle) para ejecutar tareas programadas, llamadas "cronjobs". En ocasiones puede sucedernos que creamos un cronjob, esperamos su ejecución programada, y en el log (/var/log/cron si se trata de Red Hat/Fedora/CentOS o /var/log/syslog si se trata de una distribución basada en Debian) nos encontramos con diferente tipo de errores, por ejemplo: "(CRON) bad command", "/bin/sh: Desktop: command not found", "Error: bad username; while reading" o "/bin/sh: root: command not found".

    Todos estos mensajes de error se producen cuando tenemos un problema en la sintaxis del cronjob.

  • Al intentar instalar una máquina virtual Devuan GNU+Linux sobre un host FreeBSD con VirtualBox, me encontré en reiteradas oportunidades con un fallo de entrada/salida que provocaba la corrupción del sistema de archivos.