¿Cuáles son las ventajas y desventajas de Upstart y systemd?

183

Parece que systemd es el nuevo sistema init en el bloque, igual que Upstart hace unos años. ¿Cuáles son los pros / contras de cada uno? Además, ¿cómo se compara cada uno con otros sistemas init?

init upstart systemd tshepang
fuente
44
@keith IIRC openrc simplemente utiliza SysV, la ventaja es un conjunto bien diseñado de scripts de inicio que utilizan componentes comunes y son portátiles (que significa trabajar en cualquier shell) Es una buena limpieza, pero no es realmente un nuevo initd
xenoterracide
@xeno Sí, pero realmente no se puede saber. no hay enlaces simbólicos rcX.d o [KS] en absoluto. En realidad, sysv init en sí mismo es bastante flexible, y los niveles de ejecución no se usan realmente de la manera habitual.
Keith el
Aunque el autor de este blog está en contra de systemd, sugiero que leas esto. Repasa los pros y los contras de systemd y BSD init. textplain.net/blog/2015/…
Peschke
1
Consulte la actualización de 2016 unix.stackexchange.com/a/287282/49091 también.
igaurav
Las supuestas ventajas de systemd no compensarán en 100 años el costo ya incurrido en el mundo para implementar esto. Cada minuto, hora o día dedicado por un administrador de Unix para lidiar con esta basura ya debe sumar miles de millones y ¿para qué beneficios reales, además de un par de campanas y silbatos?
Waslap

Respuestas:

90

Actualización 2016

La mayoría de las respuestas aquí tienen cinco años, así que es hora de algunas actualizaciones.

Ubuntu solía usar el sistema de arranque por defecto, pero lo abandonaron el año pasado a favor de systemd; consulte:

Debido a eso, hay un buen artículo sobre Systemd para usuarios principiantes en el wiki de Ubuntu: comparación muy detallada entre upstart y systemd y una guía de transición de upstart a systemd.

(Tenga en cuenta que, de acuerdo con el wiki de Ubuntu , aún puede ejecutarse en las versiones actuales de Ubuntu de forma predeterminada instalando upstart-sysvy ejecutando, sudo update-initramfs -upero teniendo en cuenta el alcance del proyecto systemd, no sé cómo funciona en la práctica, o si systemd es o no posible desinstalar)

La mayor parte de la información en las secciones de Comandos y Scripts a continuación está adaptada de algunos de los ejemplos utilizados en ese artículo (que tiene una licencia conveniente al igual que las contribuciones de los usuarios de Stack Exchange bajo la Licencia Creative Commons Reconocimiento-CompartirIgual 3.0 ).

Aquí hay una comparación rápida de comandos comunes y scripts simples, consulte las secciones a continuación para obtener una explicación detallada. Esta respuesta compara el comportamiento anterior de los sistemas basados ​​en Upstart con el nuevo comportamiento de los sistemas basados ​​en systemd, como se hizo en la pregunta, pero tenga en cuenta que los comandos etiquetados como "Upstart" no son necesariamente específicos de Upstart, a menudo son comandos que son comunes a todos los sistemas Linux y Unix no systemd.

Comandos

Ejecutando su:

  • advenedizo: su
  • systemd: machinectl shell

(consulte la sección "reemplazo de comando su" a continuación)

Pantalla de ejecución:

  • advenedizo: screen
  • systemd: systemd-run --user --scope screen

(consulte la sección "Eliminación inesperada de procesos en segundo plano" a continuación)

Ejecutando tmux:

  • advenedizo: tmux
  • systemd: systemd-run --user --scope tmux

(consulte la sección "Eliminación inesperada de procesos en segundo plano" a continuación)

Comenzando trabajo foo:

  • advenedizo: start foo
  • systemd: systemctl start foo

Detener el trabajo foo:

  • advenedizo: stop foo
  • systemd: systemctl stop foo

Reiniciar el trabajo foo:

  • advenedizo: restart foo
  • systemd: systemctl restart foo

Listado de trabajos:

  • advenedizo: initctl list
  • systemd: systemctl status

Comprobación de la configuración del trabajo foo:

  • advenedizo: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Listado de variables de entorno del trabajo:

  • advenedizo: initctl list-env
  • systemd: systemctl show-environment

Configuración de la variable de entorno del trabajo:

  • advenedizo: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Eliminar la variable de entorno del trabajo:

  • advenedizo: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Registros

En el inicio, los registros son archivos de texto normales en el directorio / var / log / upstart, por lo que puede procesarlos como de costumbre:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

En systemd, los registros se almacenan en un formato binario interno (no como archivos de texto), por lo que debe usar el journalctlcomando para acceder a ellos:

sudo journalctl -u foo
sudo journalctl -u foo -f

Guiones

Ejemplo de script inicial escrito en /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Ejemplo de script systemd escrito en /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

reemplazo de comando su

Un sureemplazo de comando se fusionó con systemd en la solicitud de extracción # 1022:

porque, según Lennart Poettering, "su es realmente un concepto roto" .

Explica que "puedes usar su y sudo como antes, pero no esperes que funcione por completo " .

La forma oficial de lograr un sucomportamiento similar es ahora:

machinectl shell

Lennart Poettering lo ha explicado más detalladamente en la discusión para emitir # 825:

"Bueno, ha habido largas discusiones sobre esto, pero el problema es que lo que se supone que debe hacer es muy poco claro. [...] En pocas palabras: su es realmente un concepto roto. Te dará una especie de caparazón , y está bien usarlo para eso, pero no es un inicio de sesión completo, y no debe confundirse con uno ". - Lennart Poettering

Ver también:

Matanza inesperada de procesos en segundo plano.

Comandos como:

Ya no funciona como se esperaba . Por ejemplo, nohupes un comando POSIX para asegurarse de que el proceso siga ejecutándose después de cerrar sesión en su sesión. Ya no funciona en systemd. Además, los programas como screeny tmuxdeben invocarse de una manera especial o de lo contrario, los procesos que ejecuta con ellos se eliminarán (aunque no lograr que se eliminen esos procesos suele ser la razón principal de ejecutar screen o tmux en primer lugar).

Esto no es un error, es una decisión deliberada, por lo que no es probable que se solucione en el futuro. Esto es lo que Lennart Poettering ha dicho sobre este tema:

En mi opinión, en realidad era bastante extraño para UNIX que, de forma predeterminada, permitiera que el código de usuario arbitrario permaneciera sin restricciones después del cierre de sesión. Se ha discutido desde hace mucho tiempo entre muchas personas del sistema operativo, que esto debería ser posible, pero ciertamente no debería ser el predeterminado, pero nadie se atrevió hasta ahora a cambiar el interruptor para pasar de un valor predeterminado a una opción. No limpiar las sesiones de los usuarios después de cerrar sesión no solo es feo y algo hackeo, sino también un problema de seguridad. systemd 230 ahora finalmente activó el interruptor y finalmente, por defecto, limpia todo correctamente cuando el usuario cierra la sesión.

Para más información ver:

Concepto de inicio de alto nivel

En cierto modo, systemd funciona al revés: en los trabajos iniciales comienzan tan pronto como pueden y en los trabajos de systemd comienzan cuando tienen que hacerlo. Al final del día, ambos sistemas pueden iniciar los mismos trabajos y en casi el mismo orden, pero piensas en eso mirando desde una dirección opuesta, por así decirlo.

Así es como lo explica Systemd para usuarios principiantes :

El modelo de Upstart para iniciar procesos (trabajos) está "basado en eventos codiciosos", es decir, todos los trabajos disponibles cuyos eventos de inicio se inician se inician lo antes posible. Durante el arranque, el sistema de arranque sintetiza algunos eventos iniciales como el inicio o rcS como la "raíz del árbol", los primeros servicios comienzan en esos y los servicios posteriores comienzan cuando se ejecutan los primeros. Un nuevo trabajo simplemente necesita instalar su archivo de configuración en / etc / init / para activarse.

El modelo de systemd para iniciar procesos (unidades) está "basado en dependencia perezosa", es decir, una unidad solo se iniciará si alguna otra unidad de inicio depende de ella. Durante el arranque, systemd inicia una "unidad raíz" (default.target, puede anularse en grub), que luego se expande de forma transitiva e inicia sus dependencias. Una nueva unidad necesita agregarse como una dependencia de una unidad de la secuencia de arranque (comúnmente multiusuario.target) para activarse.

Uso en distribuciones

Ahora algunos datos recientes según Wikipedia:

Distribuciones que usan upstart por defecto:

Distribuciones que usan systemd por defecto:

(Consulte Wikipedia para obtener información actualizada)

Distribuciones que no utilizan ni Upstart ni systemd:

Controversia

En el pasado, se ha propuesto una bifurcación de Debian para evitar systemd . Se creó Devuan GNU + Linux : una bifurcación de Debian sin systemd (gracias a fpmurphy1 por señalarlo en los comentarios).

Para obtener más información sobre esta controversia, consulte:

Como muchos de ustedes ya sabrán, el voto Init GR Debian promovido por Ian Jackson no fue útil para proteger el legado de Debian y sus usuarios de la avalancha del sistema.

Esta situación prevé un bloqueo en las dependencias del sistema que amenaza de facto la libertad de desarrollo y tiene serias consecuencias para Debian, su flujo ascendente y su flujo descendente.

El CTTE logró intercambiar una dependencia y ganarnos tiempo con una instalación sutil de systemd sobre sysvinit, pero incluso este proceso fue agotador y lleno de drama. Finalmente, hace una semana, Ian Jackson renunció. [...]

Renuncio al Comité Técnico con efecto inmediato.

Si bien es importante que las opiniones del 30-40% del proyecto que están de acuerdo conmigo sigan estando representadas en el TC, yo mismo soy claramente una figura demasiado controvertida en este punto para hacerlo. Debería hacerme a un lado para tratar de reducir la medida en que las conversaciones sobre la gobernanza del proyecto son personalizadas. [...]

Devuan nació de una controversia sobre la decisión de utilizarlo como el sistema de inicio predeterminado para Debian. La posición oficial de Debian en systemd está llena de afirmaciones que otros han desacreditado . Los lectores interesados ​​pueden continuar discutiendo este tema candente en La controversia del sistema . Sin embargo, lo alentamos a mantener la cabeza fría y su voz civilizada. En Devuan estamos más interesados ​​en programarlos mal que en mirar atrás. [...]

Se han creado algunos sitios web y artículos dedicados a la controversia del sistema:

Hay muchas discusiones interesantes sobre Hacker News:

También se pueden observar tendencias similares en otras distribuciones:

Filosofía

advenedizo sigue la filosofía Unix de DOTADIW: "Haz una cosa y hazlo bien". Es un reemplazo para el demonio init tradicional. No hace nada más que iniciar y detener servicios. Otras tareas se delegan a otros subsistemas especializados.

systemd hace mucho más que eso. Además de iniciar y detener servicios, también administra contraseñas, inicios de sesión, terminales, administración de energía, restablecimientos de fábrica, procesamiento de registros, puntos de montaje del sistema de archivos, redes y mucho más; vea el archivo NOTICIAS para ver algunas de las características.

Planes de expansión

De acuerdo con una Perspectiva para systemd Lo que se ha logrado y la presentación de Lo que se encuentra por delante de Lennart Poettering en 2014 en GNOME.asia, estos son los objetivos principales de systemd, áreas que ya estaban cubiertas y las que aún estaban en progreso:

objetivos del sistema:

Nuestros objetivos

  • Convierte Linux de una bolsa de bits en un sistema operativo competitivo de uso general.
  • Construyendo el sistema operativo de próxima generación de Internet Unificando diferencias sin sentido entre distribuciones

  • Llevando la innovación de vuelta al sistema operativo central

  • Escritorio, servidor, contenedor, integrado, móvil, nube, clúster,. . . Estas áreas están más juntas de lo que piensas

  • Reducción de la complejidad del administrador, fiabilidad sin supervisión.
  • Todo introspectable
  • El descubrimiento automático, plug and play es clave
  • Arreglamos las cosas donde están rotas, nunca las pegamos

Áreas ya cubiertas:

Lo que ya cubrimos:

sistema init, registro de diario, administración de inicio de sesión, administración de dispositivos, administración de archivos temporales y volátiles, registro de formato binario, guardar / restaurar la luz de fondo, guardar / restaurar rfkill, diagrama de arranque, readahead, configuración de almacenamiento encriptado, descubrimiento de partición EFI / GPT, máquina virtual / contenedor registro, gestión mínima de contenedores, gestión de nombres de host, gestión local, gestión del tiempo, gestión de semillas aleatorias, gestión de variables sysctl, gestión de consola,. . .

Trabajo en progreso:

En qué estamos trabajando:

  • administración de redes
  • systemd-networkd
  • Caché DNS local, respondedor mDNS, respondedor LLMNR, verificación DNSSEC
  • IPC en el núcleo
  • kdbus, sd-bus
  • Sincronización horaria con NTP
  • systemd-timesyncd
  • Más integración con contenedores
  • Sandboxing de servicios
  • Sandboxing de aplicaciones
  • Formato de imagen del sistema operativo
  • Formato de imagen de contenedor
  • Formato de imagen de la aplicación
  • GPT con autodescubrimiento
  • Sistemas sin estado, sistemas instanciables, restablecimiento de fábrica
  • / usr es el sistema operativo
  • / etc es la configuración (opcional)
  • / var es el estado (opcional)
  • Inicialización y actualizaciones de nodos atómicos
  • Integración con la nube
  • Gestión de servicios entre nodos
  • Imágenes del sistema operativo verificables
  • Todo el camino hasta el firmware
  • Carga de arranque

Alcance de esta respuesta

Como señaló fpmurphy1 en los comentarios, "debe señalarse que systemd ha ampliado su alcance de trabajo a lo largo de los años mucho más allá del simple inicio del sistema".

Traté de incluir la mayoría de la información relevante aquí. Aquí estoy comparando las características comunes de Upstart y systemd cuando se usan como sistemas init como se hizo en la pregunta y solo menciono características de systemd que van más allá del alcance de un sistema init porque no se pueden comparar con Startup, pero su presencia es importante entender la diferencia entre esos dos proyectos. La documentación relevante debe verificarse para obtener más información.

Más información

Más información se puede encontrar en:

Extras

El equipo de LinOxide ha creado una hoja de trucos de Linux Systemd vs SysV Init .

rsp
fuente
44
... y tal bifurcación de Debian ha ocurrido. Devuan GNU + Linux es una bifurcación de Debian sin systemd.
fpmurphy
2
Cabe señalar que systemd ha ampliado su alcance de trabajo a lo largo de los años mucho más allá del simple inicio del sistema.
fpmurphy
1
Excelente publicación y extremadamente útil para Cent guy. ¡Gracias por tomarse el tiempo señor!
origin1tech
44
@ronsmith service <foo> start/stop/restart/statustodavía funciona bien. Al igual que la mayoría del software de Unix, systemd proporciona compatibilidad de comandos con valores predeterminados bien conocidos.
Shadur
2
Muy buena respuesta. Sin embargo, un punto: los sistemas operativos BSD no son distribuciones de Linux: son sistemas operativos Unix diferentes con su propio núcleo.
Giorgio
68

Tanto upstart como systemd son intentos de resolver algunos de los problemas con las limitaciones del sistema de inicio tradicional SysV. Por ejemplo, algunos servicios deben comenzar después de otros servicios (por ejemplo, no puede montar sistemas de archivos NFS hasta que la red se esté ejecutando), pero la única forma en que SysV puede manejar eso es establecer los enlaces en el directorio rc # .d tal que uno está antes que el otro. Además, es posible que deba volver a numerar todo más tarde cuando se agreguen o cambien dependencias. Upstart y Systemd tienen configuraciones más inteligentes para definir los requisitos. Además, está el problema con el hecho de que todo es un script de shell de algún tipo, y no todos escriben los mejores guiones de inicio. Eso también afecta la velocidad de la puesta en marcha.

Algunas de las ventajas de systemd que puedo ver:

  • Cada proceso iniciado obtiene su propio cgroup o un cgroup particular.
  • Pre-creación de sockets y manejadores de archivos para servicios, similar a como lo hace xinetd para sus servicios, permitiendo que los servicios dependientes se inicien más rápido. Por ejemplo, systemd mantendrá abierto el identificador de archivo para / dev / log para syslog, y los servicios posteriores que envíen a / dev / log tendrán sus mensajes almacenados en búfer hasta que syslogd esté listo para hacerse cargo.
  • Se ejecutan menos procesos para iniciar realmente un servicio. Esto significa que no está escribiendo un script de shell para iniciar su servicio. Esto puede ser una mejora de la velocidad y (IMO) algo más fácil de configurar en primer lugar.

Una desventaja que conozco es que para aprovechar la asignación previa de socket / FH de systemd, muchos daemons tendrán que ser parcheados para que systemd les pase el FH.

jsbillings
fuente
13
PulseAudio es un sistema de sonido muy difamado ( pulseaudio.org ), originalmente escrito por Lennart Poettering, el autor de systemd. Estaba haciendo una broma aquí, porque conozco a varias personas a las que les gusta quejarse de pulseaudio y estoy seguro de que también se quejarían de systemd. Honestamente, no he tenido ningún problema con systemd o pulseaudio.
jsbillings
44
Hace casi uno pino por los abundantes fiordos de Plan9 ... todo es un archivo.
dhchdhd
44
Para ser honesto, pulseaudio fue una solución a un problema inexistente. No hay nada que PA pueda hacer que ALSA no pueda, y he escuchado MUCHAS personas que tienen problemas con PA, una y otra vez.
WhyNotHugo
3
Dos desventajas del sistema que se perdió: (1) todos los scripts de inicio deben reescribirse. (2) hay mucha menos compatibilidad con sistemas operativos que no sean de Linux (como los BSD, por ejemplo).
WhyNotHugo
8
Simplemente genial. Por favor, eche un vistazo a 0pointer.de/blog/projects/the-biggest-myths . Fui testigo del crecimiento de systemd, y puedo dar fe de que muchas de las críticas que se hacen aquí son completamente infundadas. En el enlace encontrarás golpe por golpe, refutación razonada .
vonbrand
30

Vi systemdmencionado en Arch General ML hoy. Así que léelo. El H Online como siempre es una gran fuente de tecnología Linux y es donde encontré mi lugar para comenzar a investigar Systemd como alternativa SysV Init y Upstart . Sin embargo, el artículo H Online (en este caso) no es una lectura muy útil, el uso real detrás de esto es que proporciona enlaces a las lecturas útiles.

La verdadera respuesta está en el anuncio de systemd . Lo que da algunos puntos cruciales de lo que está mal con SysV initd y qué nuevos sistemas deben hacer

  • Para empezar menos.
  • Y para comenzar más en paralelo.

Su plan principal para hacer esto parece ser iniciar los servicios solo cuando son necesarios, e iniciar un socket para ese servicio, de modo que el servicio que lo necesita pueda conectarse al socket creado mucho antes de que el demonio esté completamente en línea. Aparentemente, un socket retendrá una pequeña cantidad de datos almacenados, lo que significa que no se perderán datos durante el retraso, se manejará tan pronto como el demonio esté en línea.

Otra parte del plan parece ser no serializar los sistemas de archivos, sino montarlos a pedido también, de esa manera no está esperando su montaje, /home/etc. (no debe confundirse con /etc), y / o fsckcuándo podría los demonios iniciales como /y /var/etc. ya están montados. Dijo que iba a usar autofs para este fin.

También tiene el objetivo de crear .desktopdescriptores de inicio de estilo como reemplazo de los scripts. Esto evitará toneladas de shprocesos lentos e incluso más tenedores de procesos de cosas como sedy grepque a menudo se usan en scripts de shell.

También planean no iniciar algunos servicios hasta que se los soliciten, y tal vez incluso los apaguen si ya no son necesarios, por ejemplo, el módulo bluetooth y el daemon solo se necesitan cuando está utilizando un dispositivo bluetooth. Otro ejemplo dado es el demonio ssh. Este es el tipo de cosas que inetd es capaz de hacer. Personalmente, no estoy seguro de que me guste esto, ya que puede significar latencia cuando los necesito, y en el caso de ssh, creo que significa una posible vulnerabilidad de seguridad, si mi inetd estuviera en peligro, todo el sistema lo estaría. Sin embargo, me han informado que usar esto para violar este sistema no es factible y que si lo deseo puedo desactivar esta función por servicio y de otras maneras.

Aparentemente, otra característica será la capacidad de comenzar en función de eventos de tiempo, ya sea en un intervalo programado regularmente o en un momento determinado. Esto es similar a qué crondy atdhacer ahora. Aunque me dijeron que no admitirá el usuario "cron". Personalmente, esto suena como lo más inútil. Creo que esto fue escrito / pensado por personas que no trabajan en entornos multiusuario, no hay mucho propósito para el usuario cron si eres el único usuario en el sistema, aparte de no ejecutarse como root. Trabajo diariamente en sistemas multiusuario, y la regla siempre es ejecutar scripts de usuario como el usuario. Pero tal vez no tengo la previsión que tienen, y de ninguna manera hará que no pueda ejecutar crondo atd, por lo que no perjudica a nadie más que a los desarrolladores, supongo.

La gran desventaja de systemd es que algunos demonios tendrán que modificarse para aprovecharlo al máximo. Funcionarán ahora, pero funcionarían mejor si se escribieran específicamente para su modelo de socket.

Parece que, en su mayor parte, el problema de la gente del sistema con el advenedizo es el sistema de eventos, y creen que no tiene sentido o es innecesario. Quizás sus palabras lo expresen mejor.

O para decirlo de manera más simple: el hecho de que el usuario recién haya iniciado D-Bus no es en modo alguno una indicación de que NetworkManager debería iniciarse también (pero esto es lo que haría Upstart). Es justo al revés: cuando el usuario solicita NetworkManager, eso definitivamente es una indicación de que D-Bus también debe iniciarse (que es ciertamente lo que la mayoría de los usuarios esperarían, ¿verdad?).
Un buen sistema de inicio debe comenzar solo lo que se necesita, y eso a pedido. Ya sea perezosamente o en paralelo y de antemano. Sin embargo, no debería comenzar más de lo necesario, particularmente no todo lo instalado que pueda usar ese servicio.

Como ya he dicho, esto se discute mucho más ampliamente en el anuncio de systemd .

xenoterracida
fuente
lo siento pero el anuncio es como un libro. Tengo que leer y asimilar, antes de que realmente pueda incluir más aquí.
xenoterracide
2
¿Cómo es esto mejor que la respuesta de @ John? ¿Es un marcador de posición? ¿Una promoción de H Online ?
tshepang
1
@tshepang bueno, en realidad se vincula al anuncio del sistema d y las cosas en línea h tienen enlaces a ese y otros enlaces interesantes. Es una lectura larga y tediosa. Podría agregar más una vez que lo haya asimilado ... este no es un tema simple . Cuando escribí esto, pensé que querrías comenzar a leer más temprano que tarde. pero siéntete libre de modificarme. Ciertamente, la respuesta de @jsbillings es decente y mejor que la mía hasta ahora. pero no tan bueno como leer el anuncio en sí mismo
xenoterracide
@tshepang Probablemente agregaré más mañana, después de la cama. h cosas en línea era solo yo siendo un buen periodista y citando mis fuentes.
xenoterracide
@tshepang. He actualizado mi respuesta. estoy bastante seguro de que he terminado a menos que las personas útiles en irc: //frenode.net/systemd decidan que desean ofrecer una corrección de algún tipo.
xenoterracide
11

Bueno, una cosa que la mayoría de ustedes olvidaron es la organización de procesos en cgroups .

Entonces, si systemd inició algo, lo colocará en su propio cgroup y no hay un medio (sin privilegios) para que el proceso escape de ese cgroup. Aquí están las consecuencias de eso:

  • Un administrador de un gran sistema con muchos usuarios tiene nuevas formas eficientes de identificar usuarios / procesos maliciosos.
  • Las prioridades para la programación de la CPU se pueden determinar mejor como lo hace el "parche Wonder autocgroup" .
tshepang
fuente
8

Para obtener una visión muy detallada de systemd, comenzando con los primeros borradores de diseño (y una crítica detallada de los sistemas init existentes, incluido el sistema inicial y cómo systemd propone solucionarlos), vaya a su página de inicio . Con el tiempo, se han publicado varios artículos sobre startup en LWN . Solo tenga en cuenta que cualquier mención de systemd (o pulseaudio) allí desencadena guerras de fuego interminables.

IMVHO (y como usuario de Fedora) estoy muy contento con eso. Algo en esta línea se había retrasado mucho para manejar la complejidad de los sistemas Linux actuales. Fedora usó advenedizo por un tiempo, pero nunca salió de la etapa de ser un reemplazo elegante para sysvinit, ejecutando principalmente scripts de inicio sin cambios. Su promesa de simplificar la configuración de arranque tiene el costo de nuevamenteconfigurar manualmente las interdependencias, y eso simplemente no funciona. systemd calcula las dependencias por sí mismo (o simplemente permite iniciar cosas sin tener en cuenta las dependencias, se solucionan por sí mismas). Otra gran ventaja (algunos dicen que es una desventaja severa) es que explota las características específicas de Linux hasta el fondo (especialmente los cgroups permiten aislar un demonio y todos sus descendientes, por lo que es fácil de monitorear, limitar los recursos o matarlos como un grupo; hay muchos otros).

vonbrand
fuente
3

Registro en diario: Systemd es literalmente como la carpeta WinSXS cuando se trata de registrar cosas, crea copias de copias a menos que elimine o reduzca manualmente el tamaño del archivo que seguirá consumiendo en su disco. Lo llamo cookies del gestor de arranque.

Bert
fuente
incorrecto. esas no son copias y tiene un límite configurable freedesktop.org/software/systemd/man/journald.conf.html
amigo