SystemD vs SysVinit: algunos comandos

Publicado por Diego Córdoba en

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 SysVinitComando SystemdDescripción
service miservicio startsystemctl start miservicioReiniciar un servicio (no es persistente al reinicio)
service miservicio stopsystemctl stop miservicioDetiene un servicio (no es persistente al reinicio)
service miservicio restartsystemctl restart miservicioDetiene un servicio y lo inicia nuevamente
service miservicio reloadsystemctl reload miservicioRecarga la configuración de un servicio sin detenerlo. Depende del servicio si soporta esta opción o no.
service miservicio condrestartystemctl condrestart miservicioReinicia el servicio si ya se encuentra corriendo.
service miservicio statussystemctl status miservicioMuestra 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 onsystemctl enable miservicioActiva el servicio para iniciarse al próximo inicio del sistema.
chkconfig miservicio offsystemctl disable miservicioDesactiva el servicio para iniciarse al próximo inicio del sistema.
chkconfig miserviciosystemctl is-enabled miservicioVerifica si el servicio está activo o no al inicio del sistema operativo.
chkconfig –listsystemctl 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 –listls /etc/systemd/system/*.wants/miservicio.serviceLista para qué runlevel está activo o no un servicio.
chkconfig miservicio –addsystemctl daemon-reloadCrea 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)

systemd-vs-sysVinit-cheatsheet systemd sysinit

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!!


Diego Córdoba

- Ingeniero en Informática - Mg. Teleinformática - Tesis pendiente - Docente universitario - Investigador

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.