Si tenía la edad suficiente para usar computadoras a mediados de la década de 2000 (justo la década correcta), y estaba ejecutando Windows y Linux, y, siendo un nerd, también participó en discusiones sobre los beneficios de este sistema operativo sobre ese , entonces debe haber encontrado la siguiente declaración:no necesita hacer ningún mantenimiento del sistema en Linux, es lo suficientemente inteligente como para manejarlo todo por sí mismo.
De hecho, en el lado de Windows, a menudo se hablaba de que los sistemas se volvían más lentos con el tiempo, la necesidad imperiosa de desfragmentación (en NTFS en lugar de Ext3), la limpieza de archivos temporales, etc. Linux a menudo se promocionaba como libre de mantenimiento. Ahora, la pregunta es, ¿qué tan cierta es realmente esta afirmación? De hecho, tuve la oportunidad de probarlo por mí mismo, todo a través del azar temporal.
¿Qué pasó?
Estaba instalando y eliminando algunos paquetes en la instancia de Kubuntu 18.04 en mi Slimbook y, de repente, la operación falló. Apt, el administrador de paquetes (de línea de comandos) me dijo que no podía completar una operación, ya que no quedaba espacio en el dispositivo [sic]. Qué.
gzip:stdout:no queda espacio en el dispositivo
E:error de mkinitramfs find 141 cpio 141 gzip 1
update-initramfs:error para /boot/initrd.img-4.15.0-163-generic con 1.
dpkg:error al procesar el paquete initramfs-tools (--configure):
el subproceso de script posterior a la instalación del paquete initramfs-tools instalado devolvió el estado de salida de error 1
Se encontraron errores durante el procesamiento:
linux-image-4.15.0-166-generic
initramfs-herramientas
Lo interesante aquí es:estaba trabajando normalmente, sin interrupciones. HABÍA espacio en mi disco, aunque era relativamente pequeño (y más pequeño de lo que pensaba, pero aún quedaban unos ~20 GB en el SSD de 500 GB) y, lo que es más importante, NINGÚN mensaje o advertencia del sistema de que había un problema.
Pero luego, examiné el contenido de la partición /boot y he aquí:
df -lh /boot
Tamaño del sistema de archivos utilizado % de uso disponible Montado en
/dev/sda2 705M 705M 0M 100 % /boot
Qué. Por alguna extraña razón, mi no insignificante partición /boot se había llenado hasta el borde, lo que significaba que cualquier operación del kernel o initramfs a partir de ahora fallaría. Esto no es algo bueno, especialmente cuando pienso, oye, ¿y si hubiera una actualización del kernel?
Entonces decidí ejecutar el comando "autoremove" para apt, que limpia los paquetes no utilizados. Después de varios minutos de rigurosa purga, la situación volvió a la normalidad:
df -lh /boot
Tamaño del sistema de archivos utilizado % de uso disponible Montado en
/dev/sda2 705M 155M 500M 24 % /boot
La lección aquí
Resulta que, con una configuración de cifrado de disco completo implementada, sobre la cual no tenía control cuando la implementó el instalador hace tres años, ya que los tamaños de las diferentes particiones y demás se configuraron automáticamente, terminé quedándome sin /boot espacio después de aproximadamente 3,5 años de uso, con la cadencia típica de actualizaciones del núcleo de la familia Ubuntu.
Ahora, por supuesto, el remedio es obvio:elimine los paquetes no utilizados de vez en cuando. Para ser justos, apt SIEMPRE le dice esto cuando ejecuta cualquier comando de mantenimiento. Le dice que hay muchas cosas que se pueden eliminar, lo que debería reducir el uso del disco. En la línea de comando.
Pero. Pero. Nunca se muestra ese mensaje cuando se ejecutan administradores de paquetes GUI como, por ejemplo, Discover. Esto significa que la gente común que usa Linux en la forma clásica de escritorio, es decir, SIN magia de línea de comandos, eventualmente terminará con problemas no tan libres de mantenimiento en sus máquinas Linux, si continúan usándolas el tiempo suficiente.
Como parte de mi limpieza, también ejecuté ncdu y encontré todo tipo de cruft en el disco, incluidas muchas sobras en /var, contenedores y máquinas virtuales que no se usaron durante mucho tiempo y que sus respectivos servicios nunca limpiaron. Una vez más, algo que se puede remediar con previsión, lo que incluiría:a) una mejor separación de los directorios del sistema central de los archivos de los usuarios (sin mantener las máquinas virtuales en /var) b) una mejor limpieza automática c) advertencias y notificaciones reales para el usuario final .
He resaltado este problema general de conocimiento limitado de servicios cruzados en Linux hace mucho tiempo. Realmente no hay una verdadera cohesión. Si su sistema está atascado en un bucle de arranque, nada romperá este bucle a menos que intervenga manualmente. Si hay un servicio que ralentiza el sistema, una pieza de código con errores, algo que no se integra bien con el sistema, no hay nada que le diga eso. Todo vive en su propio espacio, y peor aún, sin ningún mecanismo de autocontrol o autocuración.
Conclusión
Esta es mi pequeña historia anecdótica. Por primera vez, me encontré con un problema. Anteriormente, usaba una sola partición raíz para mis sistemas, sin cifrado de disco, lo que significaba que /boot era tan expandible como el propio sistema, por lo que el espacio después de las actualizaciones nunca fue un problema. Pero aquí, me topé con algo que podría morder y morderá a las personas que usan sus sistemas de manera no nerd (a través de GUI) y no realizan ningún trabajo de mantenimiento manual.
La verdadera solución es hacer que los sistemas Linux sean más resistentes y tengan una gestión de errores mucho, mucho mejor, para cada servicio o programa por sí solo, y luego en todo el sistema. Eso también ayudaría a resolver toneladas de otros problemas y errores que a menudo no se detectan o no se informan, ya que las personas simplemente no tienen herramientas para descubrir qué salió mal o cómo interactúan los diferentes componentes. Bueno, allá vas. Quizás encuentres esto interesante. Nos vemos.