Continuo con el desarrollo de herramientas para ver si las termino y sigo mi camino.
Desarrollo de mydevtools
El programa skeleton está prácticamente terminado. Quedan pruebas con la gestión vía git pero lo básico está completado. Funciona bien, avisando antes de lo que no puede hacer y no según se lo encuentra, y es bastante rápido. Veremos qué tal en las pruebas de campo.
Me falta empaquetarlo y añadirle esqueletos de proyectos para poder aplicarlo a isidoro y sus módulos de acceso a la base de datos. No se llevan nada bien y me sorprende que lo haya diseñado así.
Servidor backups.venexma.net
Tengo avisos de munin acerca de la salud del disco de sistema de este servidor por lo que estoy preparándole un reemplazo. Y no, no es un disco nuevo. Es uno que le dobla la capacidad pero que está usado.
Munin me indica que hay errores S.M.A.R.T. que tampoco llego a entender asi que he hecho un diagnostico directo a ver si consigo aclararme. Y menos aún. Parece que hay un problema con un parámetro llamado Airflow_Temperature_Cel con los siguientes valores:
root@backups:~# smartctl -H /dev/sda smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-10-amd64] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Please note the following marginal Attributes: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 190 Airflow_Temperature_Cel 0x0022 062 044 045 Old_age Always In_the_past 38 (1 168 39 26 0)
Y buscando he encontrado esta explicación en la web de siempre que menciona que es un evento pasado, que ocurrió no se sabe cuándo y tuvo esos valores, pero que ahora no. La alerta ha quedado registrada, eso sí, por lo que se me ha ocurrido ver si había alguna posibilidad de anularla. Y no, como dicen en este otro sitio, SMART está diseñado para conservar ese histórico de eventos y no se puede borrar si no es con herramientas de muy bajo nivel que incluyen uso de cables especiales.
Bueno, pues entonces me centraré en que dejen de ser un problema para el programa de monitorización. Eso puedo, ¿ verdad ? Creo que sí. Y digo creo porque no lo tengo muy claro. De momento espero a que el nuevo disco pase los test de escritura y lectura en superficie para proceder a cambiarlo como disco de sistema.
El disco que estoy comprobando tiene al menos 8 sectores defectuosos que he conservado en un archivo aparte y que me servirá como ayuda cuando cree encima sistemas de archivos.
La orden de comprobación ha sido la siguiente:
# time badblocks -s -o /tmp/badblocks.txt -w /dev/sde