Como todos sabrán, Debian a partir de su versión 8.0, migró su gestor de servicios desde SysVinit a Systemd. Por otro lado, muchas distribuciones, entre ellas Arch, mi distro preferida en mi desktop, también utilizan desde hace tiempo systemd.
Runlevels vs targets
Systemd tiene el concepto de target para reemplazar el concepto clásico de runlevel de los sistemas sysvinit. Un target es similar a un runlevel, con algunas diferencias. Algunos targets incluso se crean y heredan los servicios de otro target, y a su vez, puede agregar servicios nuevos… esto nos recordará al concepto de generalización y herencia de la POO.
Un target tiene un nombre, no un número como los runlevels, y está orientado a un uso específico.
Al ser un concepto equivalente al de runlevel, se puede utilizar init o telinit para intercambiar los targets en el sistema, tal cual se hacía en sysvinit con los números de runlevel.
Los targets son directorios que se encuentran generalmente en /etc/systemd/system/ y tienen nombres similares a «mitarget.target.wants». Dentro del directorio de un target se linkean como symlink (ln -s) los archivos de servicio que se encuentran por lo general en /lib/systemd/system/ y son archivos de servicios con «extensión» .service.
A estos archivos se los denomina «archivos de unidad de servicio».
Tabla de equivalencias SysVinit y SystemD
En la siguiente tabla presento un resumen breve de equivalencias de comandos entre sysvinit y systemd:
Comando SysVinit
Comando Systemd
Descripción
service miservicio start
systemctl start miservicio
Reiniciar un servicio (no es persistente al reinicio)
service miservicio stop
systemctl stop miservicio
Detiene un servicio (no es persistente al reinicio)
service miservicio restart
systemctl restart miservicio
Detiene un servicio y lo inicia nuevamente
service miservicio reload
systemctl reload miservicio
Recarga la configuración de un servicio sin detenerlo. Depende del servicio si soporta esta opción o no.
service miservicio condrestart
ystemctl condrestart miservicio
Reinicia el servicio si ya se encuentra corriendo.
service miservicio status
systemctl status miservicio
Muestra el estado de ejecución de un servicio.
ls /etc/rc.d/init.d/
systemctl (ó) systemctl list-unit-files –type=service (ó) ls /lib/systemd/system/*.service /etc/systemd/system/*.service
Lista los servicios disponibles en el sistema.
chkconfig miservicio on
systemctl enable miservicio
Activa el servicio para iniciarse al próximo inicio del sistema.
chkconfig miservicio off
systemctl disable miservicio
Desactiva el servicio para iniciarse al próximo inicio del sistema.
chkconfig miservicio
systemctl is-enabled miservicio
Verifica si el servicio está activo o no al inicio del sistema operativo.
chkconfig –list
systemctl list-unit-files –type=service (ó) ls /etc/systemd/system/*.wants/
Imprime una lista de los servicios del sistema, indicando su estado de activación y runlevels para los que corre.
chkconfig miservicio –list
ls /etc/systemd/system/*.wants/miservicio.service
Lista para qué runlevel está activo o no un servicio.
chkconfig miservicio –add
systemctl daemon-reload
Crea un nuevo archivo de servicio, o modifica uno existente.
Una imagen vale más que mil palabras
En la siguiente imagen se ve un resumen interesante de estas equivalencias y comandos, y varias más de las que agregué en la tabla. (Click en la imagen para ver en tamaño completo)
En futuros artículos ampliaré la información, con ejemplos prácticos, manejo de journaling y otras yerbas 🙂
Espero les sirva! Se agradece si lo pueden compartir!!
Acá no puedo acompañarte amigo 🙁 systemd tiene «tufo» raro, no solo en lo enredado que hace las cosas por donde lo mires (¿dónde esta el espíritu KISS de *nix?) sino su política mmmm… no se, no tengo piel como quien diría con ésta herramienta…
SysVinit ¿tenía / tiene cosas a mejorar? si obvio que si!!! ¿es systemd la solución? lo dudo y mucho…
Cada equipo con Debian Jessie que me toca instalar (y tengo la oportunidad..) agrego los repos de Devuan y lo transformo 🙂
Gracias por comentar! La idea es mostrar algunas diferencias fundamentales, pero en gran medida coincido con tu razonamiento.
SystemD aún hoy me resulta complicado sin demasiado sentido respecto de lo que era SysVinit… de hecho en mi Arch se me complica un poco todo cuando tengo que debuggear algún problema, analizar logs, etc.
Es muy buena idea la de transformar un Debian en Devuan , o si es cuestión de comandos, instalar los comandos y gestores sysvinit en Debian.
Y sí, es cuestión de aprenderlo… para poder decidir si es mejor systemd hay que conocerlo muy bien, yo por el momento soy novato y mi tendencia es quedarme con el clásico sysvinit, que podés configurar con ojos cerrados.
El tiempo lo dirá 😛
Abrazo jobregon!!
gumer
· 21 abril, 2016 a las 03:28
Sistemd complica mucho y consume muchos recursos, no tiene como hacer un autodepurado para elinar procesos apagados, bueno bueno, aun no pruebo devuan … ni la transformación…
Sí, he notado algo de consumo de recursos en los procesos systemd-*, lo que no me termina de cerrar todavía es por qué distros ligeras como ArchLinux lo han adoptado, y corre realmente rápido.
Como le decía a Javier, todavía no me he puesto a analizarlo más a fondo, cuando lo haga postearé un review más detallado de ventajas y desventajas respecto de sysVinit 🙂
Gracias por comentar! Slds!
Hoy les voy a comentar brevemente cómo podemos conectar a una base de datos y realizar algunas consultas desde terminal y, por supuesto, desde nuestros shell scripts. Bash Scripts y las bases de datos Este Leer más…
¿Qué hace el comando type? El comando type es utilizado para obtener información sobre el tipo de un comando o función en Linux. Al ejecutarse se mostrará la ubicación del comando (archivo binario o incorporado Leer más…
Hoy analizaremos el significado del concepto de promedio de carga de procesos, o load average, en sistemas Linux… tres valores que vemos en la salida de comandos como uptime, top o htop. Respondiendo consultas de Leer más…
4 comentarios
Javier · 28 marzo, 2016 a las 18:13
Acá no puedo acompañarte amigo 🙁 systemd tiene «tufo» raro, no solo en lo enredado que hace las cosas por donde lo mires (¿dónde esta el espíritu KISS de *nix?) sino su política mmmm… no se, no tengo piel como quien diría con ésta herramienta…
SysVinit ¿tenía / tiene cosas a mejorar? si obvio que si!!! ¿es systemd la solución? lo dudo y mucho…
Cada equipo con Debian Jessie que me toca instalar (y tengo la oportunidad..) agrego los repos de Devuan y lo transformo 🙂
lsb_release -cid
Distributor ID: Devuan
Description: Devuan GNU/Linux 1.0 (jessie)
Codename: jessie
Pero bueno, hay que aprenderlo.. para no usarlo 😉
Abrazo d1cor!!
Diego Córdoba · 28 marzo, 2016 a las 18:38
Javier!
Gracias por comentar! La idea es mostrar algunas diferencias fundamentales, pero en gran medida coincido con tu razonamiento.
SystemD aún hoy me resulta complicado sin demasiado sentido respecto de lo que era SysVinit… de hecho en mi Arch se me complica un poco todo cuando tengo que debuggear algún problema, analizar logs, etc.
Es muy buena idea la de transformar un Debian en Devuan , o si es cuestión de comandos, instalar los comandos y gestores sysvinit en Debian.
Y sí, es cuestión de aprenderlo… para poder decidir si es mejor systemd hay que conocerlo muy bien, yo por el momento soy novato y mi tendencia es quedarme con el clásico sysvinit, que podés configurar con ojos cerrados.
El tiempo lo dirá 😛
Abrazo jobregon!!
gumer · 21 abril, 2016 a las 03:28
Sistemd complica mucho y consume muchos recursos, no tiene como hacer un autodepurado para elinar procesos apagados, bueno bueno, aun no pruebo devuan … ni la transformación…
Diego Córdoba · 21 abril, 2016 a las 14:15
Sí, he notado algo de consumo de recursos en los procesos systemd-*, lo que no me termina de cerrar todavía es por qué distros ligeras como ArchLinux lo han adoptado, y corre realmente rápido.
Como le decía a Javier, todavía no me he puesto a analizarlo más a fondo, cuando lo haga postearé un review más detallado de ventajas y desventajas respecto de sysVinit 🙂
Gracias por comentar! Slds!
Los comentarios están cerrados.