¿Portar viejos hábitos de Sysvinit a Systemd?

Tengo una serie de scripts con los que pude instalar y configurar nuevos sistemas estables de Debian. Para iniciar programas automáticamente, uso /etc/rc.local pero para otros casos tuve que cambiar manualmente el /etc/inittab expediente. También tengo otros cambios, como agregar --noclear a la línea 1:2345:respawn:/sbin/getty --noclear 38400 tty1 .

Debido a que tuve que personalizar el proceso de apagado, terminé haciendo esto:

l0:0:wait:/etc/rc.halt 0
...
l6:6:wait:/etc/rc.halt 6

y mi /etc/rc.halt se parece a esto

#!/bin/sh
#   
# rc.halt
#   
# This script is executed when entering level 6/0 (on halt or reboot)

su - teststand -c "/home/teststand/stop_server.sh"  # my custom command

# making sure the halt/reboot process is resumed
test -n "${1}" && /etc/init.d/rc ${1}

exit 0

Hoy fue la primera vez que instalé un nuevo Debian 8 con systemd como sistema de inicio predeterminado. No pensé en eso y primero me sorprendió que /etc/inittab faltaba el archivo.

En mis sistemas en ejecución (@work &@home) todavía estoy ejecutando mis sistemas con sysvinit y es por eso que tengo 0 experiencia con systemd .

Sé que puedo cambiar al antiguo sysvinit pero quiero ver las diferencias con systemd . Además, estoy personalizando una nueva instalación en este momento y no tengo mucho tiempo para terminarla, por eso no tengo tiempo ahora para mirar la documentación.

Mi pregunta:¿hay alguna forma de cambiar rápidamente systemd? comportamiento para que pueda agregar --noclear a getty y usando /etc/rc.halt como punto de partida para reiniciar/detener?

Básicamente, ¿puedo importar rápidamente mi antiguo inittab? cambios en systemd ?

Gracias

Respuesta aceptada:

systemd no es compatible con System 5 init , solo Sistema 5 rc .

La administración del sistema estilo Linux System 5 consta de dos partes, init que se ejecuta como proceso #1 y rc que se encarga de ejecutar scripts de inicio y parada. Estos son en realidad de dos paquetes distintos en Debian. init es del paquete sysvinit; y rc suele ser del paquete sysv-rc, pero podría ser del paquete file-rc o openrc.

/etc/inittab es un archivo de configuración procesado por init . systemd no proporciona ningún mecanismo de compatibilidad con versiones anteriores para esto. El mecanismo de compatibilidad con versiones anteriores de System 5 de systemd es solo para System 5 rc , que ejecuta los programas en /etc/init.d/ . (Es solo para ese sabor específico de rc , además. systemd no implementa ningún mecanismo de compatibilidad con versiones anteriores para los mecanismos de configuración de file-rc y openrc).

Esto no es algo específico de systemd. Más o menos no init/administrador del sistema de reemplazo (con solo 1 excepción en tres décadas) procesa /etc/inittab .

Para conectar un servicio a systemd, debe usar los mecanismos que hace apoyo, es decir, su propia unidad de servicio archivos y (a través de un generador que se convierte automáticamente en archivos unitarios) el System 5 rc archivos de configuración en /etc/init.d/ .

Olvídate de los niveles de ejecución.

Todas esas cosas de nivel de ejecución con las que está trabajando han sido declaradas "obsoletas" en los sistemas operativos systemd Linux. No hay Ejecute el nivel 0 o 6 para ingresar. No existen sin algunas correcciones de compatibilidad.

Para hacer que un servicio se ejecute al apagarse, la respuesta obvia, dada por muchos, es crear una unidad de servicio que sea WantedBy el shutdown.target . Sin embargo, esto tiene algunas trampas sutiles. Una respuesta mejor, pero menos obvia, es crear una unidad de servicio normal, con DefaultDependencies=yes para asegurarse de que entre en conflicto con el objetivo de apagado y coloque la esencia del servicio en ExecStop en lugar de en ExecStart .

[Unit]
Documentation=https://unix.stackexchange.com/questions/233561/

[Service]
Type=oneshot
User=teststand
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/teststand/stop_server.sh

[Install]
WantedBy=multi-user.target

No hagas rodar tu propio Dæmon Supervisor de Poor Man en script de shell.

Tales cosas siempre están mal escritas.

Relacionado:¿Hacer la salida tail -f en una tubería rota?

Si su "servicio" es simplemente la ejecución de un comando llamado "stop_server.sh", entonces la inferencia es que se trata de un script que detiene un servidor bajo algún sistema de gestión de servicios de shell-script desarrollado a mano.

Es para estos desastres mal escritos, destartalados, poco confiables y peligrosos:stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh

Tiene systemd. Úselo y ejecute cualquier servicio que se esté ejecutando aquí utilizando los mecanismos de administración de servicios adecuados. No necesitarás este bicho raro ExecStop -solo servicio si realiza su real servicio ejecutable a través de systemd con DefaultDependencies=true , ya que systemd se encargará de cerrar el servicio en el momento del cierre.

Tomar un supervisor de Daemon de Poor Man en un script de shell que "administra" un servicio y luego envolverlo en una unidad de servicio systemd para un segundo servicio que luego se organiza para iniciarse en el apagado, cuando el objetivo no es más que administrar el primer servicio y hacer que se apague cuando el sistema se detenga o se apague, es una buena forma de entrar en systemd House of Horror.

El mundo quiere que limpies tu pantalla.

Querer no borrar una terminal virtual entre el cierre de sesión y el inicio de sesión subsiguiente es nadar contra la corriente, como han descubierto Greg Wooledge y otros. La presencia de resultados confidenciales de usuarios privilegiados, o jefes, que quedan después del cierre de sesión ha sido un problema de seguridad para Unices (y de hecho otros sistemas operativos de acceso remoto de tiempo compartido) desde la década de 1970, y se necesita mucho esfuerzo para deshacer todo. las cosas que la gente ha puesto para evitar este problema.

• Muchos sistemas tienen una clear_console comando en sus scripts de cierre de sesión de shell como estándar. (Esto es problemático en sí mismo, ya que no funciona bien con los programas gráficos que se ejecutan en el terminal virtual del kernel #1 y no funciona con ningún otro tipo de terminal, virtual o real).

  Este comando tiene que ser eliminado.

• El valor predeterminado en los programas getty destinados a terminales virtuales, como mingetty , es borrar la terminal. (Hace esto antes de iniciar sesión, lo que significa que la salida de la terminal puede permanecer sin borrar si se detiene un servicio de inicio de sesión TTY. Irónicamente, esta funcionalidad habría sido mejor ubicada en login , que gracias a las necesidades de PAM sigue ejecutándose al cerrar la sesión).

  El --noclear La opción debe implementarse para deshabilitar esto. Esto implica escribir uno o más archivos de anulación de archivos de unidad, cambiar el ExecStart configuración, o simplemente señalando [email protected] en un archivo de unidad local creado por uno mismo.

• [email protected] suministrado por systemd conjunto de unidades de servicio de plantilla TTYVTDisallocate=yes que le indica a systemd que borre un terminal virtual del kernel. (De nuevo, esto no funciona con ningún otro tipo de terminal, ni siquiera con terminales virtuales de espacio de usuario, como se refleja en parte en su nombre).

  Esto también debe eliminarse, nuevamente con una anulación o una plantilla de servicio diferente señalada por [email protected] .

Lecturas adicionales

• Jonathan de Boyne Pollard (2015). /etc/inittab es cosa del pasado. . Respuestas frecuentes.
• https://unix.stackexchange.com/a/196014/5132
• ¿Cómo ejecutar un script con systemd justo antes de apagarlo?
• Jonathan de Boyne Pollard (2014). No abuses de su por abandonar los privilegios de usuario. . Respuestas frecuentes.
• Greg Wooledge (2014-04-08). Deja de limpiar mi maldita consola . Wiki de Greg.
• Jonathan de Boyne Pollard (2015-08-22). Congelación del sistema con múltiples ttys en Debian Jessie . [correo electrónico protegido] usuario de debian.
• https://unix.stackexchange.com/a/194218/5132
• Jonathan de Boyne Pollard (2015). La Casa del Horror systemd . Respuestas frecuentes.

Relacionado:¿Buena explicación detallada de la sintaxis de /etc/network/interfaces?