¿Por Qué Aún Existen las Carpetas rc0.d en Linux con systemd?

¿Por Qué Aún Existen las Carpetas rc0.d en Linux con systemd?

carpetas rc systemd

Un Hallazgo Curioso en Sistemas Modernos

Cualquier usuario avanzado de Linux se ha topado con esta sorpresa alguna vez. Al explorar /etc/, aparecen carpetas llamadas rc0.d, rc1.d, hasta rc6.d. Sin embargo, tu sistema arranca con systemd desde el primer segundo. Por tanto, la pregunta es inevitable: ¿qué hacen ahí esas carpetas rc systemd si nadie las usa?

Una Charla que Encendió la Duda

Esta investigación no nació de la nada, sino de una conversación técnica real. Todo comenzó charlando con Ale, desarrollador de CuerdOS Linux, otra distribución basada en Debian. Durante la charla, surgió la misma pregunta que muchos usuarios se hacen alguna vez. Así pues, decidí ir más allá de la teoría y comprobarlo en un sistema real.

El Origen Real de las Carpetas rc

Estas carpetas provienen de la era de SysV init, el sistema de arranque clásico de Unix. Antiguamente, cada «runlevel» tenía su propia carpeta con scripts de arranque y parada. No obstante, systemd sustituyó ese modelo hace más de una década. Aun así, Debian y sus derivadas, conservan esta estructura por compatibilidad.

¿Es sysv-rc el Culpable?

Muchos asumen que el paquete sysv-rc es el responsable de mantener vivas estas carpetas rc systemd. De hecho, esa fue nuestra primera hipótesis al investigar el tema. Sin embargo, una comprobación real en una instalación con 503 días de uso reveló algo distinto. El paquete sysv-rc ni siquiera estaba instalado en el sistema.

El Verdadero Responsable: init-system-helpers

Con el comando dpkg -S, la respuesta llegó clara y directa. El paquete init-system-helpers es quien realmente posee estas carpetas. Además, este paquete es una dependencia dura de dpkg, por lo que no se puede eliminar. En consecuencia, las carpetas persisten aunque el sistema use systemd al cien por cien.

Symlinks que Nunca Duermen del Todo

Al inspeccionar el contenido de esas carpetas, aparecen decenas de enlaces simbólicos activos. Curiosamente, corresponden a paquetes con soporte systemd nativo, como lightdm, cups o ssh. Esto ocurre porque sus scripts postinst todavía ejecutan update-rc.d al instalarse. Por lo tanto, cada actualización de esos paquetes regenera automáticamente los enlaces simbólicos.

Un Comportamiento Heredado del Empaquetado

Este patrón no es un fallo de systemd ni una mala configuración del sistema. Más bien, es un residuo de cómo Debian empaqueta software desde hace años. Muchos mantenedores nunca eliminaron esa línea heredada al migrar sus paquetes a systemd. Así pues, la compatibilidad quedó activa «por si acaso», sin coste real de rendimiento.

¿Puede systemd Usar Estas Carpetas?

Sí, técnicamente systemd puede leerlas gracias a un componente llamado sysv-generator. Este generador traduce scripts SysV antiguos en unidades systemd temporales durante el arranque. Sin embargo, cuando ya existe una unidad .service nativa, el generador simplemente la ignora. Por consiguiente, en sistemas modernos basados en Debian, este generador permanece inactivo.

¿Vale la Pena Eliminarlas?

Desde el punto de vista técnico, estas carpetas ocupan un espacio prácticamente insignificante en disco. Además, intentar eliminarlas de forma permanente exigiría modificar paquetes ajenos al proyecto. Cada actualización futura de Debian volvería a recrear los enlaces simbólicos automáticamente. Por ello, perseguir esta limpieza representa un esfuerzo desproporcionado frente al beneficio real obtenido.

Ética del Software Limpio vs Practicidad

Para usuarios y desarrolladores con visión de pureza del sistema, este hallazgo puede resultar frustrante. Sin embargo, la limpieza técnica válida no siempre coincide con la viabilidad práctica de mantenimiento. En este caso concreto, la «basura» no consume recursos ni representa un riesgo real de seguridad. Por lo tanto, conservarla es la decisión más razonable para cualquier distribución basada en Debian.

Conclusión: Comprender Antes de Purgar

En definitiva, estas carpetas rc systemd no son un error ni negligencia del sistema operativo. Representan una capa de compatibilidad heredada, gestionada por init-system-helpers y el empaquetado de Debian. Aunque contradicen la idea de un sistema «puro» systemd, cumplen una función de seguridad ante software legado. Por eso, entender su origen es más valioso que eliminarlas sin fundamento.

Sergi Perich

Publicaciones Similares

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.