Facultade de Informática
ADMINISTRACIÓN DE SISTEMAS OPERATIVOS GRADO EN INGENIERÍA INFORMÁTICA MENCIÓN EN TECNOLOGÍAS DE LA INFORMACIÓN SYSTEMD Nombre del grupo: AFV
Estudiante 1: Sara Fernández Martínez email 1: [email protected] Estudiante 2: Andrés Fernández Varela email 2: [email protected] Estudiante 3: Javier Taboada Núñez email 3: [email protected] Estudiante 4: Alejandro José Fernández Esmorís email 4: [email protected] Estudiante 5: Luis Pita Romero email 5: [email protected] A Coruña, mayo de 2021. Índice general
1 Introducción 1 1.1 ¿Qué es un sistema init? ...... 1 1.2 Necesidad de una alternativa ...... 1
2 ¿Qué es systemd? 2 2.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 16 8.1 Ventajas ...... 16 8.1.1 Principales ventajas ...... 16 8.1.2 Más en profundidad ...... 16 8.2 Desventajas ...... 18 8.2.1 Principales desventajas ...... 18 8.2.2 Más en profundidad ...... 18
9 Conclusiones 20
Bibliografía 21
i Índice de figuras
2.1 Ejemplo ejecución machinectl shell...... 3 2.2 Ejemplo ejecución systemd-analyze...... 3 2.3 Ejemplo ejecución systemd-analyze-blame...... 4 2.4 Ejemplo ejecución systemd-analyze-critical-chain...... 4
5.1 journalctl ...... 7 5.2 journalctl opcion -r ...... 8 5.3 journalctl opcion -f ...... 8 5.4 journalctl opcion -nx ...... 9 5.5 journalctl opcion –since –until ...... 9 5.6 journalctl opcion UID ...... 9 5.7 journalctl opcion -u ...... 10 5.8 journalctl opcion -b ...... 10 5.9 journalctl opcion -k ...... 11 5.10 hostnamectl ...... 11
6.1 Versión systemctl...... 12 6.2 Listar unidades...... 12 6.3 Unidad activa?...... 13 6.4 Unidades fallidas...... 13 6.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 la BIOS 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 cuales determinan el nivel de ejecución del sistema. Cada runlevel determina el subconjunto de servicios o daemons que serán iniciados durante el inicio del sistema, aunque el runlevel 0 y el 6 estan reservados para 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 dicho archivo /etc/rc determina qué servicios se inician. La ventaja de este sistema es que es simple y fácil de mantener pero es propenso a errores dado que un mínimo error en el script puede detener el inicio del 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 de forma secuencial, lo que provocaba largos tiempos de inicio del sistema, o que si un servicio fallaba el proceso de inicio se quedaba bloqueado. Estos ejemplos sumados otros defectos de diseño motivaron la creación de systemd, que fue pensado para mejorar la eficiencia del proceso de inicio init de System V. [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 unsistema operativo, en una definición un poco más formal, es un conjunto de daemons de administración de sistema, bibliotecas y herramientas que fueron diseñados para interactuar con el núcleo del sistema operativo GNU/Linux.
Es el primer proceso en el arranque de Linux que se ejecuta en el espacio de usuario, por lo que también se considera el proceso padre de todos los procesos hijos que existen en dicho espacio. Es importante resaltar que se trata de un software libre y de código abierto y que uno de sus principales objetivos es unificar configuraciones básicas de Linux y los comportamientos de servicios en todaslas distribuciones. [3]
2.1 Un poco de historia
Systemd fue desarrollado en un inicio por Lennart Poettering y Kay Sievers, entre otros, ambos son ingenieros de software que trabajaban para Red Hat e iniciaron el desarrollo de systemd enel2010, 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 arranque del 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ón importante 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 detectando diversos 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 una lista 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 observa como imprime un árbol de la cadena de unidades de tiempo crítico(para cada una de las UNIDADES especificadas 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 archivo de configuración propio que tendrá una extensión distinta conforme al tipo de unidad4 tratada[ ]:
• .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 por systemd.
• .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 recursos comunes (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 utilizado por varios sistemas operativos Unix-like para realizar tareas durante el arranque del sistema) ofrece compatibilidad con SysV (comando service y chkconfig) para aquellos servicios que aún soportan o funcionan únicamente con scripts de inicio SysV (aunque actualmente no hay muchos servicios que lo hagan)[5]. Upstart pese a mantener compatibilidad con los comandos service y chkconf de SysV implementó su propia utilidad para la administración de servicios, de igual modo systemd lo hace con la herramienta systemctl. SysV habilitaba servicios con chkconfig (o reproducía listas de estos para ver cuál de ellos se ejecutaba al arranque), algo que ahora bajo systemd podemos hacer con los siguientes comandos: 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.service se consideran equivalentes.
• Los puntos de montaje se traducirán automáticamente en la correspondiente unidad .mount. Por ejemplo 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 adicionales para 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 los logs del sistema sin importar el proceso que los origine. Por defecto, el comando utilizado sin argumentos muestra todos los contenidos del journal, iniciando con la entrada más antigua que fue guardada. Cada usuario podrá ver sus propios journals, sin embargo, el acceso a los archivos de 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 primeros debajo, 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 las iremos 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 últimas x 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 cierta fecha, 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ón UID=número: nos permite mostrar 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 ha ejecutado 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 utilizan systemd y nos permite configurar el nombre del sistema. Por ejemplo: para cambiar el nombre de 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 una zona 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 del administrador 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 enel sistema además del estado en el que se encuentran.
Figura 6.2: Listar unidades.
Systemctl is-enabled
12 CAPÍTULO 6. SYSTEMCTL
Figura 6.3: Unidad activa?.
Systemctl –failed muestra todas las unidades fallidas.
Figura 6.4: Unidades fallidas.
Systemctl status
Figura 6.5: Estado de una unidad.
Para gestionar las diferentes unidades systemctl cuenta con las siguientes opciones [11]:
• systemctl start
• systemctl stop
• systemctl restart
• systemctl kill
• systemctl enable
13 CAPÍTULO 6. SYSTEMCTL
• systemctl disable
• systemctl clean
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 para tu 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 GRUB compatible con sistemas EFI. De hecho, systemd-boot, al ser un sistema de alto nivel, se enlaza con el bootlader nativo de la propia UEFI y ofrece un subconjunto de funciones básicas para seleccionar el sistema operativo. En cambio, GRUB es diferente en ese sentido, y carga un sistema más completo para 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 con miles de líneas que no depende del resto de systemd, aunque se agregó a éste por su simplicidad. Al estar relacionado con éste, las unidades de arranque no tendrán la misma nomeclatura que GRUB, sino que 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 para sistemas EFI las nuevas versiones de GRUB también lo hacen. En cambio, systemd-boot solo trabaja con 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 realizar administraciones 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 sistema operativo 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 enel directorio donde se encuentran los ficheros de configuración para agregar multiboot para esos nuevos sistemas. Resumiendo, si quieres mayor flexibilidad, más capacidad de configuración/administración, GRUB sigue siendo tu mejor opción. En cambio, si quieres algo simple, veloz y robusto, sencillo de mantener y 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 algunos o, si lo miramos por otro lado, es tan bueno como se afirma?. Bien, veamos a continuación las ventajas y 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 la configuración de alta disponibilidad con software como un marcapasos.
• Systemd extiende las funciones del registro del sistema de muchas maneras con la herramienta journald 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 incurrido por el proceso de arranque.
• Systemd hace que los procesos de arranque sean mucho más sencillo, eliminando la necesidad de satisfacer dependencias gracias a D-Bus(sistema de comunicación entre procesos), su activación de socket y la integración de udev(gestor de dispositivos, su función es controlar los ficheros de dispositivo en /dev).
8.1.2 Más en profundidad
Comenzaremos por explicar algunos contextos ventajosos para el uso de systemd. Empezando con 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 sistemas init más establecidos, nos encontramos con que este proceso de arranque de la máquina resulta ser extremadamente rápido.
Pese a no estar estrictamente pensado para un arranque rápido, vemos que la ventaja de gozar de independencia total a la hora de iniciar una máquina ayuda a tener los procesos que se van llamando mucho más controlados, no es posible que surjan retrasos debido a procesos ajenos que tarden en cargar.
Nos otorga, como bien se expuso anteriormente, sencillez en el código y los ficheros de arranque de la máquina, ya que sólo nos encontraremos ficheros de systemd que realizan las diversas tareas a llevar a cabo durante el proceso. Lo mismo ocurre si llevamos nuestra vista a los ficheros de configuración del sistema, la configuración de red y muchos otros recursos y servicios de los que disponemos en una 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 implementan este init, no tendríamos que preocuparnos de la sintaxis, de los comandos, las equivalencias, los flags y en general ninguna variación entre sistemas Operativos. Desde Solaris hasta FreeBSD, pasando por ubuntu, 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 precisamente habitual encontrarse con gente no iniciada al mundo de la informática utilizando un ordenador con una 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 tunning que estas distribuciones poseen, que echa atrás a mucha gente que sólo quiere realizar su trabajo sin pelearse mucho con la máquina. Systemd aportaría una aproximación más automatizada del enfoque UNIX, que si bien es configurable en algunos aspectos como pequeño añadido para las personas que saben, 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 computadores de empresa, y sincronizarlos todos aún más y de forma sencilla y centralizada mediante estos plugins compatibles con systemd.
17 CAPÍTULO 8. VENTAJAS Y DESVENTAJAS DE SYSTEMD
8.2 Desventajas
8.2.1 Principales desventajas
• Controla muchas 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 minuciosamente el 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 capacidad para 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 causar caí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 se necesita configurar ambos y no se puede usar solo un script desysv.
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 un ayudante.
Si nos ponemos a ver la historia y filosofía de los sistemas UNIX y el estándar POSIX queéstos siguen, nos daremos cuenta de que, sin ninguna duda, estos Operativos se diseñaron, programaron e implementaron para realizar de forma óptima y altamente configurable una serie de funciones básicas que, de ser combinadas, desarrollan el verdadero potencial del software abierto, pudiendo así crear complejos scripts que realicen funciones muy avanzadas, aspecto impensable en los otros sistemas mencionados. Es en este momento cuando vemos a systemd y comprendemos que es un paso bastante grande a la retaguardia de esta filosofía, acercándose al control de la máquina que, aunque centralizado y estandarizado, inevitablemente acarrea menos opciones de configuración, funcionalidades pensadas par aun único uso y más complejas, que quizá hasta realicen varias tareas a la vez. Como vemos, todo un paso en contra de la idea inicial.
Otro golpe lo tenemos con el potencial de convertir a las distribuciones UNIX en un sistema más enfocado a todos los públicos, independientemente de su conocimiento. Como se explicó antes, el alto control nos cierra puertas en cuanto al uso y configuración de aspectos de tunning en un sistema altamente 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 puede suponer y de hecho supuso una reacción de rechazo y odio por parte de un sector importante de la comunidad, dividiéndola de forma significativa y causando que algunos informáticos, reacios a aceptar esta situación, prefieran quedarse con las distribuciones más antiguas y perdiendo el feedback quelos sistemas 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 de que 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 necesarios para 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 sistema tan rígido y controlador no hará más que complicar las tareas a un administrador, o a cualquier usuario con 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 pelearse constantemente 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 si eran controladas por handlers, nada impide a un administrador crearse su propia configuración sin mayor problema más allá de cometer algún error y hacer que no funcione a la primera. De nuevo, con systemd, 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 de la 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á, puede llegar a ser hasta recomendable para iniciar en una distribución linux e irse adentrando de forma progresiva en el mundo de los ordenadores y la computación, hasta puede que en el mundo de la administración de sistemas. Sin embargo, no podemos ignorar las trabas que supone dicho sistema, y la cantidad de limitaciones que podrían venir derivadas de esta forma de pensamiento para aquellos usuarios 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 se ven algunas opiniones y dependiendo de lo que se quiera del sistema, pero no estaría de más tomarse cinco minutos para volver a pensar con la filosofía de UNIX y ofrecer alguna alternativa más cercana al método tradicional que pueda suplir las necesidades del sector que, de no hacerlo, se quedará con má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]. Disponible en: 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