En LinOxide han hecho una chuleta que nos muestra las equivalencias entre sysVinit el veterano sistema de inicio con el que la mayoría hemos empezado en GNU/Linux y systemd que fue diseñado para reemplazar al mencionado init como primer proceso (y último) que se ejecuta en el espacio de usuario y del que dependen los demás.
De tal manera que con algunas excepciones (ahí tenemos a Gentoo con openRC y Slackware que todavían resisten al invasor 🙂 ) se ha convertido en el sistema de inicio por defecto en las distros linuxeras.
Si bien systemd supone una gran oportunidad para la estandarización en algunos aspectos claves de Linux, también ha recibido críticas y tiene adversarios que lo califican como
una bofetada repugnante y violenta en la cara de la filosofía Unix
ya sabéis aquello de «hacer solo una cosa y hacerla bien» que en algunas ocasiones también tiene sus ventajas cuando surge algún error, ya que suele ser más fácil descubrir a que se debe.
Y es que systemd es todo lo contrario de eso, para bien y para mal ya no es un simple reemplazo para init puesto que integra más partes del sistema, es un «super servicio» que además de permitir la ejecución paralela de procesos y una mayor velocidad en el arranque, intenta reemplazar varios servicios del sistema como journal, la administración de energía o la gestión de red por poner algunos ejemplos.
Una de las características de systemd más celebradas es la implementación de cgroups, los grupos de control que agrupan conjuntos de procesos organizados jerarquicamente y que se pueden obligar a funcionar bajo los mismos criterios, permitiendo manejar aspectos como el uso de RAM, CPU, o establecer prioridades.
En todo caso no ha surgido una alternativa real a systemd (ya sabéis «show me the code!«) y pese a las críticas la mayoría de los proyectos y distribuciones GNU/Linux han decidido apostar libremente por el.
Pero no he venido a daros mi opinión sobre systemd o sysVinit que es básicamente neutral (entre otras cosas porque para hablar con fundamento debería leer mucha más documentación), y en el fondo tampoco es que me preocupe demasiado, si el día de mañana sale un sistema de inicio mejor estoy seguro que dada la naturaleza del software libre no tardara en ser adoptado, y si por el contrario continúa systemd será señal de que no es tan malo como algunos argumentan, en todo caso yo hasta ahora no he tenido problemas con él.
A lo que venía es a recomendaros la interesante chuleta que decora el post, creada por los colegas de LinOxide que nos muestra las equivalencias de comandos entre sysVinit y los que ahora utiliza systemd, concretamente el comando systemctl.
Una chuleta o cheetsheat que también podéis descargar en PDF
¿Y qué hay con respecto a Upstart de Canonical?
its dead! cuando Debian se decantó por systemd en vez de upstart también supuso que Canonical abandonara este último en sus próximas versiones.
Supongo que demasiado trabajo en solitario ahora que está metida en otras batallas tipo Mir o el tema de los móviles
En mi país (Chile), chuleta es la costilla de un animal (vacuno, cerdo, etc). En menor medida, también lo empleamos a las bofetadas y que te duelen (Ejemplo 1: A ese sujeto le dieron un chuletazo. Ejemplo 2: Recibí una chuleta) y parece que en España es similar a tabla (no de madera, sino a las tablas que existen en los documentos) ¿O me equivoco?
menos belico que el torpedo en la pierna de una compañera.
Más bien sería un ayuda memoria. Lo que en Argentina llamamos un machete.
Exacto y también acá en Chile a este tipo de documentos les decimos «mata burros»
En España además eran unos papelitos que los estudiantes (de primaria principalmente) utilizábamos para copiar en los exámenes sin que nos viera el profesor.
Las había de todos los tamaños y diseños (eran muy populares las que se enrollaban dentro de los bolis BIC) y dependiendo de la materia en ocasiones llevaba más tiempo hacer la chuleta que memorizar las lecciones correspondientes XD
Acá en Chile los llamamos «torpedos» xD
Será que tenia hambre, pero mire la palabra «chuleta» y me imagine un jugoso cerdo preparado al horno!!!
Pos a mi me gusta systemd, lo veo más cómodo para un user end
ea…
pues de momento systemd, por lo menos en mis debian testing es un autentico desastre. Han dejado de funcionar muchas cosas que ahora depende de el. Un simple montaje de una unidad usb es un calvario
Hoy por hoy y en la medida que he estado estudiando los inits en Linux es que he ido entendiendo todo el revuelo en torno a systemd, sin embargo y mas allá de si es con systemd o no, hace falta una estandarización (así se escribe?), por motivos académicos y laborales desde hace un tiempo me he puesto a estudiar «en serio» Linux y es muy poco practico (en tanto que ese tiempo se puede usar en aprender materias nuevas) tener que aprender como manejar servicios de dos maneras distintas que es lo que sucede cuando estudias Linux, pues debes manejar como mínimo las 2 distros referentes en el área de servidores que son Debian y Red Hat y cada una de estas tienen formas distintas, localizaciones de las configuraciones que difieren y pensandolo bien al día de hoy si estudias Linux debes aprender o tener nociones de como funcionan 3 inits: system V, upstart, systemd, insisto poco práctico.
Así es… cosas bastante extrañas pasan en debian testing con los USB montados, por suerte siendo root y por terminal, puede salvarte.
Por el momento mi viejo conocido «service samba stop/start/restart» sigue funcionando, no se que sucederá cuando termine la migración en esta distro.
Me la copio para posibles olvidos, aunque es bastante facil de manejarse con systemd. Yo por ahora encantado con el desde Arch
Gracias por el post! Con Systemd ha desaparecido el fichero /etc/inittab en el que se podía poner en respawn un proceso lanzándolo en el arranque. ¿Existe alguna forma de replicar ese comportamiento con Systemd? Hasta ahora sólo he conseguido lanzar scripts en el arraque que arrancan y mueren pero no en foreground.
Gracias!
La verdad ni idea… aunque revisando la documentación el equivalente debería ser:
Restart=on-failure
o
RestartSec
en este ultimo caso supongo que para poner a dormir un rato el servicio antes que se reinicie.
Aquí hay un artículo de un desarrollador de systemd quizás te sirva de orientación:
http://0pointer.de/blog/projects/watchdog.html
y aquí de un usuario de Debian que plantea una solución más original:
http://forums.debian.net/viewtopic.php?f=5&t=122427
Pero lo dicho…como no lo he probado ni idea si funciona.
A ver si alguien más te puede ayudar.
Un saludo!
Muchas gracias!
El primer paso es siempre saber qué hay que buscar…
Encontré esto,
http://n3mesisfixx.blogspot.com.es/2012/08/migrate-etcinittab-job-to-systemd-in.html
Ahora ya funciona perfecto 😉
saludos!!!
De nada!
Me alegro que hayas encontrado la solución!
Un saludo!
Hola, quería agradecerte y felicitarte por tu blog. Hace poco mas de un año que lo vengo leyendo, desde que empecé en el mundo FOSS/GNU/linux, me ha ayudado muchisimo a solucionar cosas y a aprender. Todo es claro, prolijo, con novedades interesantes y le transmitís un ambiente agradable y con buena onda.
En estos días tenía una ensalada de conceptos mezclados con sysvinit y systemd. Y el articulo a pesar de tener sus años, una vez mas me ayudó. Por favor me podrías despejar una ultima duda?
los comandos update-rc.d e insserv pertenecen al viejo sysvinit? Serian equivalentes a systemctl enable?
Saludos
Es como dices, pertenecen al viejo init y son sustituidos por systemctl enable, disable, start, stop, status…seguidos del servicio o script correspondiente.
En su momento mencioné algo sobre el sistema de logs con journalctl (systemd):
https://lamiradadelreplicante.com/2015/03/29/ver-los-logs-del-sistema-en-linux-con-journalctl/
A todo esto, muchas gracias por seguir el blog, me alegra de que te haya sido de utilidad en algún momento.
Un saludo!