Facultade de Informática

ADMINISTRACIÓN DE SISTEMAS OPERATIVOSGRADO EN INGENIERÍA INFORMÁTICA

MENCIÓN EN TECNOLOGÍAS DE LA INFORMACIÓN

SYSTEMDNombre del grupo: AFV

Estudiante 1: Sara Fernández Martínezemail 1: sara.fernandez4@udc.esEstudiante 2: Andrés Fernández Varelaemail 2: andres.fvarela@udc.esEstudiante 3: Javier Taboada Núñezemail 3: javier.taboada.nunez@udc.esEstudiante 4: Alejandro José Fernández Esmorísemail 4: a.esmoris@udc.esEstudiante 5: Luis Pita Romeroemail 5: l.pitar@udc.es

A Coruña, mayo de 2021.

Índice general

1 Introducción 11.1 ¿Qué es un sistema init? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Necesidad de una alternativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 ¿Qué es systemd? 22.1 Un poco de historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Units 5

4 Compatibilidad de systemd con SysV 6

5 Utilities 7

6 Systemctl 12

7 Systemd-boot: una alternativa a GRUB 15

8 Ventajas y Desventajas de Systemd 168.1 Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8.1.1 Principales ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168.1.2 Más en profundidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8.2 Desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188.2.1 Principales desventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188.2.2 Más en profundidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

9 Conclusiones 20

Bibliografía 21

i

Índice de figuras

2.1 Ejemplo ejecución machinectl shell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Ejemplo ejecución systemd-analyze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Ejemplo ejecución systemd-analyze-blame. . . . . . . . . . . . . . . . . . . . . . . . . . 42.4 Ejemplo ejecución systemd-analyze-critical-chain. . . . . . . . . . . . . . . . . . . . . . 4

5.1 journalctl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75.2 journalctl opcion -r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.3 journalctl opcion -f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.4 journalctl opcion -nx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.5 journalctl opcion –since –until . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.6 journalctl opcion UID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.7 journalctl opcion -u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.8 journalctl opcion -b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.9 journalctl opcion -k . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.10 hostnamectl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6.1 Versión systemctl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.2 Listar unidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.3 Unidad activa?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.4 Unidades fallidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136.5 Estado de una unidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ii

Capítulo 1

Introducción

1.1 ¿Qué es un sistema init?

Cuando se inicia una máquina Linux, se ejecuta un código incorporado, el cuál es cargado desde laBIOS o UEFI, seguido del bootloader, que carga un kernel de Linux según la configuración que tenga.El kernel carga los controladores e inicia init como primer proceso (con PID 1).

El diseño de init tuvo una discrepancia entre los sistemas Unix System V y BSD.

En el esquema System V se usa /etc/inittab para establecer los runlevels disponibles, los cualesdeterminan el nivel de ejecución del sistema. Cada runlevel determina el subconjunto de servicios odaemons que serán iniciados durante el inicio del sistema, aunque el runlevel 0 y el 6 estan reservadospara apagar y reiniciar el sistema respectivamente.

En el init de BSD se ejecuta el script de inicialización /etc/rc y no existen runlevels sino que dichoarchivo /etc/rc determina qué servicios se inician. La ventaja de este sistema es que es simple y fácilde mantener pero es propenso a errores dado que un mínimo error en el script puede detener el iniciodel sistema.

1.2 Necesidad de una alternativa

El sistema init tenía limitaciones en su diseño, como por ejemplo que los servicios se iniciaban deforma secuencial, lo que provocaba largos tiempos de inicio del sistema, o que si un servicio fallaba elproceso de inicio se quedaba bloqueado. Estos ejemplos sumados otros defectos de diseño motivaronla creación de systemd, que fue pensado para mejorar la eficiencia del proceso de inicio init de SystemV. [1] [2]

1

Capítulo 2

¿Qué es systemd?

Tal y como lo definen sus autores, se trata de un ”bloque de construcción básico” para un sistemaoperativo, en una definición un poco más formal, es un conjunto de daemons de administración desistema, bibliotecas y herramientas que fueron diseñados para interactuar con el núcleo del sistemaoperativo GNU/Linux.

Es el primer proceso en el arranque de Linux que se ejecuta en el espacio de usuario, por lo quetambién se considera el proceso padre de todos los procesos hijos que existen en dicho espacio. Esimportante resaltar que se trata de un software libre y de código abierto y que uno de sus principalesobjetivos es unificar configuraciones básicas de Linux y los comportamientos de servicios en todas lasdistribuciones. [3]

2.1 Un poco de historia

Systemd fue desarrollado en un inicio por Lennart Poettering y Kay Sievers, entre otros, ambos soningenieros de software que trabajaban para Red Hat e iniciaron el desarrollo de systemd en el 2010,con él intentaron superar las eficiencias de daemon de inico de varias formas:

• Mejorar el marco de software para expresar las dependencias.

• Permitir que se realicen un mayor número de procesamientos en paralelo durante el arranquedel sistema.

• Reducir la sobrecarga computacional del shell.

A lo largo de los años systemd se ha convertido en el sistema de inicio predeterminado de dis-tintas distribuciones de Linux, pero destacar que fue Fedora, en el año 2011, la primera distribuciónimportante de Linux en habilitar systemd de manera predeterminada.

2

CAPÍTULO 2. ¿QUÉ ES SYSTEMD?

Para terminar mencionar que en 2015 systemd comenzó a proporcionar un shell de inicio de se-sión, invocable mediante machinectl shell 2.1 y a lo largo de años posteriores se han ido detectandodiversos bugs de seguridad que permitían realizar ataques DoS 1 contra systemd.

Figura 2.1: Ejemplo ejecución machinectl shell.

A continuación mostramos algunos ejemplos de ejecución con el comando ”systemd”.

En esta primera figura 2.2 vemos como al utilizar el comando systemd-analyze nos muestra infor-mación de las estadísticas de rendimiento de arranque del sistema.

Figura 2.2: Ejemplo ejecución systemd-analyze.

Ahora, en la siguiente imagen 2.3 al utilizar el comando systemd-analyze blame nos imprime unalista de todas las unidades en ejecución, ordenadas por el tiempo que tardaron en inicializarse.

1 DoS: Denial of Service

3

CAPÍTULO 2. ¿QUÉ ES SYSTEMD?

Figura 2.3: Ejemplo ejecución systemd-analyze-blame.

Y por último con el uso del comando systemd-analyze critical-chain en la figura 2.4 se observacomo imprime un árbol de la cadena de unidades de tiempo crítico(para cada una de las UNIDADESespecificadas o para el objetivo predeterminado en caso contrario). Además después del caracter ’@’,se imprime El tiempo después de que la unidad esté activa o iniciada.

Figura 2.4: Ejemplo ejecución systemd-analyze-critical-chain.

4

Capítulo 3

Units

Todo lo que es gestionado por systemd se llama ”unit” y cada una de ellas es descrita por un archivode configuración propio que tendrá una extensión distinta conforme al tipo de unidad tratada [4]:

• .service: fichero que describe la configuración de un demonio.

• .socket: describe la configuración de un socket(tipo UNIX o TCP/IP) asociada a un .service.

• .device: describe un dispositivo hardware reconocido por el kernel que esté gestionado porsystemd.

• .mount: describe un punto de montaje gestionado por systemd.

• .automount:describe un punto de automontaje asociado a un .mount.

• .swap: describe una partición o archivo de intercambio gestionado por systemd.

• .target: describe un grupo de Units.

• .path: describe una carpeta o archivo monitorizado por la API Inotify delk kernel.

• .timer: describe la temporización de una tarea programada con el programador systemd.

• .slice: describe un grupo de Units asociadas a procesos para administrar y limitar los recursoscomunes (CPU, memoria…). Además utiliza internamente los ”cgroups” del kernel.

Los archivos de configuración de las Units pueden estar repartidos en tres carpetas distintas:

• /usr/lib/systemd/system : Para units proporcionadas por los paquetes instalados en el sistema.

• /run/systemd/system : Para units generadas en tiempo real durante la ejecución del sistema.Son no persistentes.

• /etc/systemd/system : Para units proporcionadas por el administrador del sistema.

5

Capítulo 4

Compatibilidad de systemd con SysV

Systemd, al igual que Upstart(reemplazo basado en eventos para el daemon init, método utilizadopor varios sistemas operativos Unix-like para realizar tareas durante el arranque del sistema) ofrececompatibilidad con SysV (comando service y chkconfig) para aquellos servicios que aún soportan ofuncionan únicamente con scripts de inicio SysV (aunque actualmente no hay muchos servicios quelo hagan)[5]. Upstart pese a mantener compatibilidad con los comandos service y chkconf de SysVimplementó su propia utilidad para la administración de servicios, de igual modo systemd lo hace conla herramienta systemctl. SysV habilitaba servicios con chkconfig (o reproducía listas de estos para vercuál de ellos se ejecutaba al arranque), algo que ahora bajo systemd podemos hacer con los siguientescomandos: Para habilitar el servicio httpd al arranque del sistema:

• systemctl enable httpd.service

Para listar todas las unidades de servicios instaladas:

• systemctl list-unit-files

O solo aquellas que se encuentran en activadas:

• systemctl list-units

Podemos apreciar que a la hora de pasar el nombre del servicio lo hacemos con el nombre completo,es decir, incluyendo su sufijo, pero existen una serie de atajos:

• Si no se especifica el sufijo, systemctl asumirá que es .service. Por ejemplo netcfg y netcfg.servicese consideran equivalentes.

• Los puntos de montaje se traducirán automáticamente en la correspondiente unidad .mount. Porejemplo si especifica /home será equivalente a home.mount.

• Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspon-diente unidad .device, por lo tanto, la especificación /dev/sda2 es equivalente a dev-sda2.device.

6

Capítulo 5

Utilities

Una de las características más importantes de systemd es que incluye varias utilidades adicionalespara realizar tareas específicas. Las principales utilidades que podemos destacar son las siguientes:

• systemctl: Herramienta que nos permite controlar y administrar servicios systemd.[6]

• journalctl: Utilidad que nos permite centralizar la administración e inspección de varios de loslogs del sistema sin importar el proceso que los origine. Por defecto, el comando utilizado sinargumentos muestra todos los contenidos del journal, iniciando con la entrada más antigua quefue guardada. Cada usuario podrá ver sus propios journals, sin embargo, el acceso a los archivosde logs principales y a los logs de otros usuarios solo puede ser visto por usuarios privilegiados.[7]

Figura 5.1: journalctl

7

CAPÍTULO 5. UTILITIES

– opción -r: nos permite mostrar la salida del comando en orden invertido, los primerosdebajo, y los últimos encima. Por ejemplo: journalctl -r 5.2.

Figura 5.2: journalctl opcion -r

– opción -f: nos permite ver el journal del ordenador en tiempo real, y las nuevas líneas lasiremos viendo entrar a las salida del comando. Por ejemplo: journalctl -f 5.3.

Figura 5.3: journalctl opcion -f

8

CAPÍTULO 5. UTILITIES

– opción -nx: nos permite limitar, en este caso particular, la salida a solamente las últimasx líneas. Por ejemplo: journalctl -n7 5.4.

Figura 5.4: journalctl opcion -nx

– opción -since -until: nos permite filtrar la salida mostrando únicamente los logs de ciertafecha, hora, o en un rango de tiempo.Por ejemplo: journalctl –since ”10 minutes ago” –until”2 minutes ago” 5.5.

Figura 5.5: journalctl opcion –since –until

– opciónUID=número: nos permitemostrar los eventos de el usuario con ese UID concreto.Por ejemplo: sudo journalctl UID=1000 5.6.

Figura 5.6: journalctl opcion UID

9

CAPÍTULO 5. UTILITIES

– opción -u: nos permite mostrar los logs de generados por un servicio concreto. Por ejem-plo: journalctl -u ureadahead.service 5.7.

Figura 5.7: journalctl opcion -u

– opción -b: para mostrar el log del inicio del ordenador, útil para saber si un servicio se haejecutado correctamente o para detectar anomalías. Por ejemplo: sudo journalctl -b 5.8.

Figura 5.8: journalctl opcion -b

10

CAPÍTULO 5. UTILITIES

– opción -k: para mostrar los mensajes de kernel. Por ejemplo: sudo journalctl -k 5.9.

Figura 5.9: journalctl opcion -k

[8]

• hostnamectl: Es una herramienta que se puede utilizar en las últimas versiones que utilizansystemd y nos permite configurar el nombre del sistema. Por ejemplo: para cambiar el nombrede nuestro equipo sería ”sudo hostnamectl set-hostname nombreDeNuestroEquipo” 5.9.

Figura 5.10: hostnamectl

• timedatectl: Herramiento que nos da la posibilidad de cambiar la hora del sistema. Ejemplos:cambiar la hora del sistema ’sudo timedatectl set-time ”2021-04-02 12:55:14”’ y establecer unazona horaria ’sudo timedatectl set-timezone ”Africa/Cairo”’.[9]

11

Capítulo 6

Systemctl

Systemctl es una utilidad de systemd que se utiliza para introspectar y controlar el estado deladministrador de sistemas y servicios ”systemd”.

A continuación se mostrarán diversas funciones que puede realizar systemctl [10]:Lo primero que habría que hacer sería comprobar que systemctl está en el sistema y funciona

correctamente, para ello se realizaría una acción tan típica como comprobar su versión 6.1.

Figura 6.1: Versión systemctl.

La opción list-unit-files nos permite mostrar los archivos de unidad que están instalados en elsistema además del estado en el que se encuentran.

Figura 6.2: Listar unidades.

Systemctl is-enabled <unidad> nos indica si la unidad inidicada está activa.

12

CAPÍTULO 6. SYSTEMCTL

Figura 6.3: Unidad activa?.

Systemctl –failed muestra todas las unidades fallidas.

Figura 6.4: Unidades fallidas.

Systemctl status <nombre unidad> nos muestra información sobre el estado del servicio indicado.

Figura 6.5: Estado de una unidad.

Para gestionar las diferentes unidades systemctl cuenta con las siguientes opciones [11]:

• systemctl start <nombre unidad> –> Inicia una unidad.

• systemctl stop <nombre unidad> –> Detiene una unidad.

• systemctl restart <nombre unidad> –> Realiza un stop y un start de la unidad.

• systemctl kill <nombre unidad> –> ”Mata” una unidad.

• systemctl enable <nombre unidad> –> Habilita una unidad y crea enlaces simbólicos codifi-cados en las secciones [Instalar] de los archivos de unidad indicados.

13

CAPÍTULO 6. SYSTEMCTL

• systemctl disable <nombre unidad> –> Deshabilita una unidad y elimina los enlaces simbó-licos.

• systemctl clean <nombre unidad> –> Borra la configuración, estado, cache y el runtime deuna unidad.

14

Capítulo 7

Systemd-boot: una alternativa a GRUB

Una alternativa a nuestro querido GRUB y que puede gestionar todo el proceso de arranque paratu distribución. Su nombre es systemd-boot. ¿Realmente nos compensa sustituir GRUB por systemd-boot? Anteriormente systemd-boot se conocía como gummiboot, un nuevo competidor con GRUBcompatible con sistemas EFI. De hecho, systemd-boot, al ser un sistema de alto nivel, se enlaza conel bootlader nativo de la propia UEFI y ofrece un subconjunto de funciones básicas para seleccionarel sistema operativo. En cambio, GRUB es diferente en ese sentido, y carga un sistema más completopara ofrecerte más opciones para administrar el sistema y con mayores capacidades[12].

En cuanto al código, ambos son de código abierto, pero en el caso de systemd-boot es software conmiles de líneas que no depende del resto de systemd, aunque se agregó a éste por su simplicidad. Alestar relacionado con éste, las unidades de arranque no tendrán la misma nomeclatura que GRUB, sinoque se llamarán por su nombre registrado en el fichero de configuración de systemd.

Si tienes un BIOS, es decir, un sistema sin EFI, ya sabes que GRUB puede funcionar bien, y parasistemas EFI las nuevas versiones de GRUB también lo hacen. En cambio, systemd-boot solo trabajacon sistemas EFI puesto que depende de éste. En cuanto a simplicidad,no ofrece opciones de confi-guración como GRUB, es veloz por su simplicidad y más robusto, pero te limita a la hora de realizaradministraciones como se pueden hacer en GRUB antes de acceder al sistema operativo.

Por otro lado, systemd-boot usa ficheros de configuración separados por cada kernel o sistemaoperativo presente, y resulta simple de mantener cuando hay varios de ellos. Así mismo, puedes di-rectamente copiar los ficheros de configuración para los nuevos sistemas que quieres arrancar en eldirectorio donde se encuentran los ficheros de configuración para agregar multiboot para esos nuevossistemas.

Resumiendo, si quieres mayor flexibilidad, más capacidad de configuración/administración, GRUBsigue siendo tu mejor opción. En cambio, si quieres algo simple, veloz y robusto, sencillo de mantenery configurar, pero sin tantas opciones, entonces puedes elegir systemd-boot…

15

Capítulo 8

Ventajas y Desventajas de Systemd

Hay todo tipo de opiniones con respeto a systemd, pero ¿es systemd tan malo como dicen algunoso, si lo miramos por otro lado, es tan bueno como se afirma?. Bien, veamos a continuación las ventajasy desventajas de este ”bloque de construcción básico” [13].

8.1 Ventajas

8.1.1 Principales ventajas

• La puesta en marcha y el monitoreo de servicios centralizado de systemd facilitan mucho laconfiguración de alta disponibilidad con software como un marcapasos.

• Systemd extiende las funciones del registro del sistema de muchas maneras con la herramientajournald y éste puede ser integrado perfectamente con el demonio de rsyslog.

• Systemd es muy rápido, aproximadamente tarda 1 segundo en arrancar. A pesar de no estar dise-ñado pensando en la velocidad, al hacer las cosas correctamente evita cualquier retraso incurridopor el proceso de arranque.

• Systemd hace que los procesos de arranque seanmuchomás sencillo, eliminando la necesidad desatisfacer dependencias gracias a D-Bus(sistema de comunicación entre procesos), su activaciónde socket y la integración de udev(gestor de dispositivos, su función es controlar los ficheros dedispositivo en /dev).

8.1.2 Más en profundidad

Comenzaremos por explicar algunos contextos ventajosos para el uso de systemd. Empezandocon el dato de que es software que, al ser totalmente independiente de otros procesos que puedan

16

CAPÍTULO 8. VENTAJAS Y DESVENTAJAS DE SYSTEMD

generar retrasos, además de no necesitar sistemas de comunicación como d-bus en el resto de sistemasinit más establecidos, nos encontramos con que este proceso de arranque de la máquina resulta serextremadamente rápido.

Pese a no estar estrictamente pensado para un arranque rápido, vemos que la ventaja de gozar deindependencia total a la hora de iniciar una máquina ayuda a tener los procesos que se van llamandomucho más controlados, no es posible que surjan retrasos debido a procesos ajenos que tarden encargar.

Nos otorga, como bien se expuso anteriormente, sencillez en el código y los ficheros de arranque dela máquina, ya que sólo nos encontraremos ficheros de systemd que realizan las diversas tareas a llevara cabo durante el proceso. Lo mismo ocurre si llevamos nuestra vista a los ficheros de configuracióndel sistema, la configuración de red y muchos otros recursos y servicios de los que disponemos enuna máquina UNIX. Un punto a favor de systemd podría ser también el inmenso potencial de estan-darización que puede traer, pues si nos ponemos a imaginar que todas las distribuciones implementaneste init, no tendríamos que preocuparnos de la sintaxis, de los comandos, las equivalencias, los flagsy en general ninguna variación entre sistemas Operativos. Desde Solaris hasta FreeBSD, pasando porubuntu, debian y derivados, todas las distribuciones seguirían un estándar sencillo y rápido.

Una ventaja poco comentada al respecto de esta forma de operar tan controladora y centralizada es,a efectos prácticos, la que más le gusta a los usuarios comunes de computadores. No es precisamentehabitual encontrarse con gente no iniciada al mundo de la informática utilizando un ordenador conuna distribución UNIX, pese a ser totalmente gratuita, frente a software como el de Windows o Apple.Una de las razones por las que podría pasar esto es la enorme y abrumadora capacidad de tunningque estas distribuciones poseen, que echa atrás a mucha gente que sólo quiere realizar su trabajo sinpelearse mucho con la máquina. Systemd aportaría una aproximación más automatizada del enfoqueUNIX, que si bien es configurable en algunos aspectos como pequeño añadido para las personas quesaben, ayudaría a popularizar los sistemas de código abierto en el mundo actual.

Otro aspecto a comentar es que systemd se ha hecho pensando en la integración con diversas aplica-ciones que puedan ser de utilidad en entornos específicos, como rsyslog, marcapasos y otros daemons.Podría estudiarse pues, la idea de utilizar sistemas UNIX tanto en servidores como en computadoresde empresa, y sincronizarlos todos aún más y de forma sencilla y centralizada mediante estos pluginscompatibles con systemd.

17

CAPÍTULO 8. VENTAJAS Y DESVENTAJAS DE SYSTEMD

8.2 Desventajas

8.2.1 Principales desventajas

• Controlamuchas cosas, al seguir la filosofía unix se asegura que haga una sola cosa y la haga bien,el problema se da cuando el software hace varias cosas ya que hay que revisar minuciosamenteel error, donde está y verificar por qué está fallando.

• Todos los demonios están muy agrupados e integrados lo que dificulta la sustitución por alter-nativas más ligeras o más cómodas para ciertos usuarios, además de que no ofrece la capacidadpara crear su propio motor de políticas de cgroup.

• Los archivos de la herramienta jounald se almacenan como binarios por ende deben de ser con-sultados utilizando journalctl, esto es un problema ya que archivos muy grandes pueden causarcaídas en sistemas de recursos ilimitados y esto los vuelve altamente corruptibles.

• Systemd no es portátil. Mantener un sistema con systemd y otros inits es más trabajo ya que senecesita configurar ambos y no se puede usar solo un script de sysv.

8.2.2 Más en profundidad

En base a lo anterior, y partiendo de los puntos en contra que le encontramos a este nuevo software,veremos como en muchos casos systemd resulta ser más un enemigo con el que pelearse en vez de unayudante.

Si nos ponemos a ver la historia y filosofía de los sistemas UNIX y el estándar POSIX que éstossiguen, nos daremos cuenta de que, sin ninguna duda, estos Operativos se diseñaron, programaron eimplementaron para realizar de forma óptima y altamente configurable una serie de funciones básicasque, de ser combinadas, desarrollan el verdadero potencial del software abierto, pudiendo así crearcomplejos scripts que realicen funciones muy avanzadas, aspecto impensable en los otros sistemasmencionados. Es en este momento cuando vemos a systemd y comprendemos que es un paso bastantegrande a la retaguardia de esta filosofía, acercándose al control de la máquina que, aunque centralizadoy estandarizado, inevitablemente acarrea menos opciones de configuración, funcionalidades pensadaspar aun único uso y más complejas, que quizá hasta realicen varias tareas a la vez. Como vemos, todoun paso en contra de la idea inicial.

Otro golpe lo tenemos con el potencial de convertir a las distribuciones UNIX en un sistema másenfocado a todos los públicos, independientemente de su conocimiento. Como se explicó antes, el altocontrol nos cierra puertas en cuanto al uso y configuración de aspectos de tunning en un sistemaaltamente pensado para eso y, como tal, con un grupo de usuarios habituales que están acostumbrados

18

CAPÍTULO 8. VENTAJAS Y DESVENTAJAS DE SYSTEMD

a la flexibilidad de systemV y similares. En este entorno en el que se sitúan estas distribuciones puedesuponer y de hecho supuso una reacción de rechazo y odio por parte de un sector importante de lacomunidad, dividiéndola de forma significativa y causando que algunos informáticos, reacios a aceptaresta situación, prefieran quedarse con las distribuciones más antiguas y perdiendo el feedback que lossistemas UNIX tienen al ser de código abierto.

Un punto que a corto plazo y sin darle demasiadas vueltas pueda parecer algo positivo es el hecho deque systemd, al menos de forma aparente, simplifica la gestión y administración del sistema, contro-lándolo todo bajo la suposición de que el usuario no controla o no tiene los conocimientos necesariospara hacer configuraciones o siquiera tocar la configuración del sistema.

El problema es, de nuevo, la comunidad a la que se orientan este tipo de distribuciones. Un sistematan rígido y controlador no hará más que complicar las tareas a un administrador, o a cualquier usuariocon ciertos conocimientos sobre la materia que desee probar nuevas ideas en su computador. Se verácon una enorme barrera que impone trabas y desea controlarlo todo en todo momento, situando asíal usuario en un escenario en el que se debe adaptar a la forma de gestión del software, o pelearseconstantemente con la compatibilidad con el mismo. Si vemos los sitemas antiguos, y pese a sus fallas,no contaban con este problema pues si bien había procesos y funcionalidades determinadas, aún sieran controladas por handlers, nada impide a un administrador crearse su propia configuración sinmayor problema más allá de cometer algún error y hacer que no funcione a la primera. De nuevo, consystemd, se siente como un retroceso.

19

Capítulo 9

Conclusiones

Cerrando con el análisis, podemos concluir que el sistema que proporciona systemd es radicalmen-te diferente a lo que se imaginaba bajo los estándares UNIX y posiblemente venga de la influencia dela premisa de crear software usable por todos sin acarrear muchos problemas.

Teniendo en cuenta a systemd tal y como es, y sabiendo lo que hará y lo que no permitirá, puedellegar a ser hasta recomendable para iniciar en una distribución linux e irse adentrando de formaprogresiva en el mundo de los ordenadores y la computación, hasta puede que en el mundo de laadministración de sistemas. Sin embargo, no podemos ignorar las trabas que supone dicho sistema, yla cantidad de limitaciones que podrían venir derivadas de esta forma de pensamiento para aquellosusuarios que lo único que desean es su entorno modificable al gusto.

Por este motivo, y ya cerrando el tema, systemd puede no ser tan malo como se hace pensar si seven algunas opiniones y dependiendo de lo que se quiera del sistema, pero no estaría de más tomarsecinco minutos para volver a pensar con la filosofía de UNIX y ofrecer alguna alternativa más cercanaal método tradicional que pueda suplir las necesidades del sector que, de no hacerlo, se quedará conmáquinas en principio superadas por las nuevas versiones.

20

Bibliografía

[1] “¿quién es init?” [En línea]. Disponible en: https://www.linuxito.com/gnu-linux/nivel-alto/262-quien-es-init

[2] “Systemd - lo que necesita saber.” [En línea]. Disponible en: https://vidatecno.net/systemd-lo-que-necesita-saber/

[3] “Systemd.” [En línea]. Disponible en: https://es.wikipedia.org/wiki/Systemd

[4] J. Antó, “Systemdjavierantó.” [En línea]. Disponible en: https://www.javieranto.com/kb/GNU-Linux/Sistema/Systemd/

[5] “Sobre systemd.” [En línea]. Disponible en: https://nebul4ck.wordpress.com/2015/02/11/sobre-systemd-mejoras-en-systemd-units-y-targets-uso-de-systemctl-compatibilidad-con-sysv/

[6] “Explorando las utilidades de systemd.” [En línea]. Disponible en: https://blog.carreralinux.com.ar/2016/08/utilidades-de-systemd/

[7] “Systemctl, trabaja con los servicios desde la terminal.” [En línea]. Disponible en: https://ubunlog.com/systemctl-trabaja-servicios-terminal/

[8] “Journalctl, algunos comandos interesantes.” [En línea]. Disponible en: https://juncotic.com/journalctl-comandos-interesantes/

[9] “Systemd y compañía: más herramientas útiles.” [En línea]. Disponible en: https://blog.carreralinux.com.ar/2016/09/mas-herramientas-systemd/

[10] “How to manage ‘systemd’ services and units using ‘systemctl’ in linux.” [En línea]. Disponibleen: https://www.tecmint.com/manage-services-using-systemd-and-systemctl-in-linux/

[11] “systemctl(1) — linux manual page.” [En línea]. Disponible en: https://man7.org/linux/man-pages/man1/systemctl.1.html#top_of_page

21

BIBLIOGRAFÍA

[12] “Systemd-boot: una alternativa a grub.” [En línea]. Disponible en: https://www.linuxadictos.com/systemd-boot-una-alternativa-a-grub.html

[13] “Systemd,¿quién está equivocado sobre él?” [En línea]. Disponible en: https://debiandulce.blogspot.com/2017/07/systemd-la-rosa-con-espinas.html

22