Question

Quiero traer al debate la existencia de systemd, hoy en día ya fué adoptado por muchas de las distros más populares... Me gustaría escuchar fundamentos, enojos, opiniones, y experiencias de cada uno.

 

Por mi parte cada día Lennardito me cae peor...

Answer 1

Fundamente.

Si no fundamentas, no tiene sentido la pregunta.

Comments

Están usandolo productivamente?

Answer 2

Para mi le falta mucho para funcionar en servers, me ha pasado que firewalld pierda reglas y se corten servicios, problemas con visualizacion de logs y alguna cosa mas que no recuerdo ahora.

Lennardito deberia ser director de marketing de M$, en eso es buenisimo....

Comments

Donde laburo nos manejamos con Debian, este año cuando salio Debian 8 fuimos pasando uno por uno los servidores que corrian Debian 7 a 8. Despues de eso tambien actualizamos la mayoria de las VMs.

Solo un servidor tuvo problemas con systemd, por algun motivo raro fallaba el multipath y no levantaba. Lo mas raro es que tenemos otros 5 servidores que tienen la misma configuración y hardware muy similar y no tuvieron problema en levantar el multipath.

Esos problemas que mencionas la verdad suenan muy raros...

Tenemos unas vms con CentOS 7 que también usan systemd y cero dramas.

---

Con qué versión de firewalld perdiste reglas!?
Acordate que si no hacés un --permanent cuando agregás la regla o un --runtime-to-permanent más adelante, cuando reincies el servicio o recargues las reglas con --reload vas a perder cualquier cambio que hayas hecho.

---

No me acuerdo la version pero el problema era que el cgroup de firewalld tenia poca memoria y cuando se llenaba no se cargaban modulos de kernel y obviamente no funcionaban las reglas de netfilter que dependian de esos modulos. Nunca encontre, ni yo ni mis compañeros, la forma efectiva de aumentarle esa memoria.
Lo otro que no me gusta de firewalld es que sigue siendo mas simple agarrar un archivo de texto y armar el firewall a mano que aprender la sintaxis de firewall-cmd, o sea agrega complicacion al pedo.

Pasa lo mismo con los logs, encontrar un log muy especifico con journalctl es como ganarse la loteria.

Otra cosa que no es buena de systemd es el ego de los desarrolladores, por unos ajustes de tuercas que recibieron de Linus empezaron a planificar forkear linux y sacar GNU/Systemd. Yo no tengo drama con que lo hagan pero si algo hizo que crezca GNU/Linux fue el aporte descentralizado del que quiera aportar al proyecto que quiera y eso es lo contrario de lo que quieren lograr los muchachos de systemd centralizando todo (en systemd y en ellos mismos).

Saludos

---

Hiper interesante lo de tu issue para estar atento.
Sobre lo de "GNU/systemd" algo me veía venir... habrá que esperar a ver en qué deriva.
Saludos!

Answer 3

Una de las principales críticas a Systemd es que hace demasiado, para ser un proceso init (con pid:1). Se encarga de los logs (que son binarios y solo se pueden leer con uno de los comandos provistos por systemd), de configuracion de dispositivos, de la red, y varias cosas mas que no recuerdo, pero de la que hay harta info por ahi.

Tener un monstruo con tanta cantidad de ingerencias es contraproducente. Hace muchas cosas... y no se si las hace bien, lo contrario a la filosofía del "hacé una cosa, pero hacela bien". Ademas, aumenta enormemente la superficie de ataque. Y como corre como proceso init, si crashea, te tira abajo el sistema completo (por eso el init es muy sencillo, y casi no hace nada mas que heredar procesos huérfanos).

Disclaimer: no tengo experiencia en el uso de systemd, lo que se lo leí en algunas páginas que argumentan por qué es malo. La mayoría toma el contenido de Boycott SystemD. Link a contenido en español: http://www.linuxito.com/gnu-linux/nivel-alto/431-por-que-systemd-es-una-mierda

Answer 4

DISCLAIMER: a recontra favor.

Para mi el rechazo tiene que ver con una serie de factores, algunos con más y otros con menos peso pero que generalmente se reducen a desconocimiento en algunos casos ó cuestiones subjetivas ('no es lo que me gusta', 'así - no lo veo - yo') en otros:

1. Es distinto: para qué tengo que aprender algo de nuevo si lo que ya existía funcionaba?
2. Es binario! No es editable! Es el Mono de los sysadmines! Un caballo de troya codeado por reptilianos Illuminati para adelantar el NWO!
3. Es monolítico.
4. No es acorde a la filosofía Unix porque no hace una sola cosa y nada más que eso, bien.

• Porque ataca problemas que se venían workaroundeando desde hace años;
• Por incorpora un sistema de ejecución preemptivo de tareas en donde es infinitamente más fácil planificar el orden y las reglas de activación que con un sistema pasivo tradicional como SysV o Upstart en donde dependemos de condicionales de ejecución previos para imaginarnos posibles escenarios resultantes sobre los que vamos a trabajar;
• Hay un montón de gente inteligente que después de analizarlo y sopesarlo está de acuerdo con que los beneficios son mayores al 'desgarro' generacional que implica abrazar el cambio;
• Porque hace que la gestión del sistema sea una seda: es una navaja suiza muy cómoda;
• Porque permite estandarizar la creación de unidades de servicio y timers haciendo infinitamente más fácil la vida del sufrido sysadmin administrador de ambientes heterogéneos;
• Porque las unidades de servicio le brindan al sysadmin un control granular sobre la ejecución de la herramienta, con un nivel de control similar al esperable de SELinux;
• Porque implementa, bien hecho, la gestión de zócalos para la activación de servicios o eventos del sistema -- evitando así estar corriendo servicios continuamente a la escucha de una eventual llamada que puede ser vulnerados y que además consumen recursos continuamente;
• Porque es container-ready :)
• Porque systemd-nspawn se siente un fucking SDF-1 al lado de chroot;
• Fundamental: porque se hace cargo de proyectos que estaban abandonados o en muy malas condiciones;
• Porque implementa PAM a nivel global haciendo todavía más cómoda la gestión del sistema;
• Porque la ejecución de las unidades es predecible y controlable;
• Porque al ser el PID 1 además es el fucking rey del sistema. Systemd cuenta con características de seguridad únicas que ni SELinux puede soñar alcanzar gracias a ser el PID 1;
• Es fucking compilado... and alive, mwahahahaha!!
• Para los que dicen que 'justamente, no es compilado, con los scripts de inicio podía revisarlos y ver qué hacían cada uno'... BS. Seriously. Todos hemos visto scripts de inicio de más de 1k líneas llenos de ugly hacks y workarounds para hacer cosas para las que Bash nunca fue pensado. Systemd corta con toda esa melange y divide la lógica operativa entre operador compilado y operando scripteable (unidades de servicio);
• Al contrario que con otros PID 1 que fueron armándose de a poco y a los ponchazos, systemd está diseñado de forma cohesiva desde el principio para gestionar de forma íntima e integral las distintas partes del sistema;
• El código es enteramente FOSS, el no saber C no es excusa para criticar la adopción del lenguaje.
• Nada más lejos de ser monolítico, de hecho es modular: en sistemas que no utilizan systemd y es necesario tenerlo presente por cuestiones externas (GNOME, por ejemplo) pueden reducirse las dependencias a unos pocos archivos muy livianos;
• Tampoco es cierto que no respeta la filosofía de diseño Unix: los proyectos que incorporó / se comió - como whatever les sea más grato decirlo - son proyectos que o estaban abandonados upstream, estaban en modo mantenimiento o estaban atados con alambre. Resulta que nadie se ocupaba de esos proyectos fundamentales para el sistema operativo pero cuando sí lo hace un grupo de personas con las que otro grupo de personas no está de acuerdo, está mal que lo hagan. Aunque dichos proyectos hoy se transformaron en modulos funcionales bien mantenidos dentro del paraguas de systemd / freedesktop, los mismo siguen siendo opcionales. Si mañana alguien desea reemplazar cualquiera de ellos puede, tranquilamente, deshabilitar la funcionalidad interna y acoplar una solución distinta al esquema systemd. Por supuesto que al ser systemd el PID1 y gestor del sistema cualquier nuevo módulo / desarrollo que pretenda ocupar el puesto de alguno de los módulos internos deberá incorporar la interfaz necesaria para comunicarse con systemd. Again, en este caso particular, systemd vino a llenar un hueco que estuvo abandonado por mucho tiempo pero pocos estaban al tanto y otros que sí lo estaban no se preocuparon demasiado por revertir la situación. Ahora, para rasgarse las vestiduras, todos mandados a hacer!
• Cientos de características awesome de las que sólamente he leído y a las que todavía no tuve oportunidad de aprender a usar =(
• Linux is not Unix. We are in 2015 -- almost 2016. Stop it.

Comments

Mi anécdota de uso de systemd está vinculada a Arch:
Arch Linux supo tener uno de los sistemas de inicio más simples y eficaces, inspirado en el init de FreeBSD que sin ser engorroso como lo es OpenRC *cof* permitía gestionar integralmente el inicio del sistema, cargar módulos o por ejemplo despejar race-conditions. Era adorable.
Un día apareció una sombra negra que en poco tiempo se comió y reemplazó al viejo y querido sistema de inicio por algo totalmente nuevo, distinto, raro... WTF!!
Superado el cimbronazo y bronca iniciales al ir descubriendo systemd me dí cuenta que las sombras eran más una proyección mía que la realidad. De hecho, al poco tiempo de usarlo se hizo evidente que volver a nuestro querido rc.conf hubiera sido regresar a la edad de piedra, minga iba a cambiar lo que ahora estaba usando por eso!

Bottom line:
Ayer leí una entrada de blog [0] que creo ilustra de forma muy correcta la postura que debemos tomar frente a determinadas piezas de ingeniería, especialmente las que no son de nuestro agrado:
"Good engineers always base their design desicions on careful analysis, experiments, and measurements, not politics. If a library works pretty well, it does not really matter where it comes from or it belongs to which camp. If it’s free software and it’s suitable for our need, I’d say 'use it'."

Saludos.
[0] http://blog.lxde.org/?p=1340

---

Btw, les dejo un video interesante:
"Jordan Hubbard - FreeBSD: The Next 10 Years
Here's a video of Jordan Hubbard's talk on the next 10 years of FreeBSD that I posted about earlier. The interesting bits about init systems (and where he indicates the necessity of having something like systemd in place) starts around 27:23."
https://www.youtube.com/watch?v=Mri66Uz6-8Y

Interesante esta parte en que Mr. Hubbard comenta lo poco que le importa que la comunidad se enoje con el cambio, no sólo con un nuevo init similar a systemd sino con el resto de las nuevas implementaciones de diseño:
https://www.youtube.com/watch?v=Mri66Uz6-8Y&t=43m47s