El cambio más grande que viene con Ubuntu 15.04 es el cambio de upstart a systemd como predeterminado para administrar el arranque y el inicio del servicio del sistema.
¿Alguien podría explicar adecuadamente a un usuario no técnico cómo y si esto nos afecta en absoluto? ¿Y por qué es importante?
Los usuarios legos no deberían notar ningún cambio, por diseño. Es un sistema init, no es algo con lo que los usuarios interactúan tradicionalmente. Debería reemplazar por completo la funcionalidad proporcionada por Upstart, y hacer algunas cosas adicionales, pero la única vez que un usuario no técnico verá esto es cuando sale mal.
Los usuarios, administradores de sistemas y desarrolladores que han estado usando y desarrollando activamente para Upstart son las personas que necesitan abordar las cosas. Hay un documento de migración en Ubuntu Wiki para ayudar a los desarrolladores a convertir sus scripts de inicio, pero los usuarios y los sysops pueden seguir usando Upstart al seguir con 14.04 (que es compatible hasta 2019).
La razón y la justificación del cambio realmente no fueron del lado de Ubuntu. Canonical estaba bastante contento con Upstart (su proyecto), pero muchos usuarios de Debian querían pasar a un motor de inicio moderno para obtener una mejor concurrencia en el arranque y una mejor funcionalidad de monitoreo en todos los servicios.
Eso significó una pelea entre varias opciones (los fundamentos) y systemd finalmente ganó.
Canonical se unió a Debian porque es más fácil y probablemente el mejor. Llegan a abandonar un proyecto y no luchan río arriba. También nos pone en línea con otras distribuciones (Red Hat, Fedora, etc.) que también se están moviendo a systemd. Más enfoque y menos duplicación de esfuerzos.
tl; dr Para una persona no técnica, esto no debería afectarlo en absoluto. Para Ubuntu debería significar menos trabajo y un mejor sistema de inicio.
¿Alguien podría explicar adecuadamente a un usuario no técnico cómo y si esto nos afecta en absoluto?
En teoría, esto no debería afectar al usuario final no técnico que no se involucra en el meollo del funcionamiento del sistema. En la práctica, hay muchas cosas que vas a ver.
Aquí hay una lista incompleta:
init+ rcson mordidos por el hecho de que systemd solo es compatible con el Sistema 5 rc. Al igual que el sistema inicial, y de hecho la mayoría de los otros sistemas, profesa y suministra, no hay compatibilidad con el Sistema 5 inity su archivo de configuración /etc/inittab.Entonces, las personas que siguieron los consejos de los 30 años de personas que aconsejaron "Bueno, puedes editar esto en /etc/inittab...", o las personas que usan softwares que siguieron ese consejo ahora tienen softwares que no comienzan con bootstrap. Ejemplo: https://unix.stackexchange.com/a/196197/5132
shutdowncomando systemd , como podría hacerlo con los shutdowncomandos anteriores . Aparte del hecho de que se llama modo de rescate en la jerga systemd, el modo de rescate no se considera un estado apagado en la visión del mundo systemd. Es considerado como un estado en ejecución . shutdown nowApagará la máquina. Es systemctl rescuealcanzar el modo de usuario único en el mundo systemd. Más información: https://unix.stackexchange.com/a/196471/5132--useropción de systemctl. Eso no se aplica a Ubuntu (todavía). upstart y systemd difieren significativamente en esta área, y la versión 15 de Ubuntu todavía usa el inicio por sesión de upstart en lugar de una instancia de systemd por usuario . Entonces https://superuser.com/a/860598/38062 no se aplicará, por ejemplo. ☺Como otros ya han señalado aquí, en teoría, esto no debería afectar al usuario final no técnico, y en teoría no hay diferencia entre teoría y práctica, pero en la práctica sí.
Creo que pocas cosas publicadas aquí necesitan alguna aclaración:
Es un sistema init, no es algo con lo que los usuarios interactúan tradicionalmente.
Fue el caso con SysV init y con Upstart, pero ya no es el caso con systemd. Hace muchas cosas con las que los usuarios interactúan tradicionalmente:
Debería reemplazar por completo la funcionalidad proporcionada por Upstart, y hacer algunas cosas adicionales
Dos cosas para aclarar: primero sobre reemplazar completamente Upstart:
Uno de los problemas que tiene la gente con systemd es que no ejecuta scripts de inicio SysV. Entonces, hay un ejemplo de que no reemplaza completamente la funcionalidad proporcionada por Upstart.
Esto es algo en lo que podríamos confiar durante más de 30 años y, tradicionalmente, usted escribió scripts de inicio SysV para una portabilidad máxima sin repetirse (escribiendo múltiples versiones de los mismos scripts), lo cual ya no es el caso.
Esto no debería ser un problema cuando se usan solo paquetes de repositorios oficiales porque presumiblemente todos los paquetes que solían tener sysV init o Upstart necesitarían reescribirse sus scripts antes de empaquetarse.
Solo será un problema para las personas que utilicen algún software personalizado o de terceros que tenga sus scripts de inicio escritos para SysV init o para Upstart y que necesitarán reescribir los scripts de inicio antes de actualizar a un sistema con systemd (u obtener el advenedizo instalado, que también es una opción , o migrar a un sistema que no usa systemd).
Hay systemd-sysv-generator que se supone que traduce automáticamente los scripts de inicio de SysV a scripts de systemd, pero hay algunos errores y una larga lista de incompatibilidades explícitas .
Ahora, la segunda aclaración: sobre esas pocas cosas adicionales:
Esas "pocas cosas adicionales" que cubrirá systemd, de acuerdo con una Perspectiva para systemd, lo que se ha logrado y la presentación de Lies Ahead de Lennart Poettering en 2014 en GNOME.asia, son las siguientes:
Volviendo a: "Es un sistema de inicio, no es algo con lo que los usuarios interactúen tradicionalmente". - Hay que señalar que el sistema init es solo un elemento en esa lista.
Y finalmente, lo último que me gustaría comentar:
[L] a vez que un usuario no técnico verá esto es cuando sale mal.
Oh, que alivio. :)
Los cambios más notables para los usuarios finales (que no sean los propios scripts) es iniciar y detener servicios y usar comandos como:
que 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 opción de diseño, 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 hasta ahora nadie se atrevió a cambiar el interruptor para pasar de un valor predeterminado a una opción. No limpiar las sesiones de los usuarios después del cierre de 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:
screenscreensystemd-run --user --scope screen(Nota: el comportamiento de "upstart" anterior es realmente cualquier cosa excepto systemd, esto no es específico de upstart)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Consulte mi respuesta a ¿Cuáles son los pros / contras de Upstart y systemd? Para obtener más detalles que están fuera del alcance de esta pregunta).
También hay una gran diferencia en el manejo de los registros porque, a diferencia de la tradición de Unix, los registros de systemd se almacenan en archivos binarios en un formato personalizado, por lo que en lugar de:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
necesita usar comandos especiales para acceder a sus registros:
sudo journalctl -u foo
sudo journalctl -u foo -f
La introducción de systemd primero a Debian y luego a Ubuntu no estuvo exenta de controversias y una gran oposición, como es sabido por cualquiera que haya escrito uno de los siguientes artículos:
La posición oficial de Debian en systemd y la controversia resultante condujo a la declaración de Exodus en 2014 y terminó con la renuncia de Ian Jackson .
Nacieron las iniciativas Init Freedom , Without-Systemd.org y Systemd-Free.org , con mucha discusión en Hacker News .