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 .