¿Existe una forma estándar de iniciar y detener servicios en Linux?

15

Hasta hace poco, había una manera simple y efectiva de iniciar / detener / reiniciar servicios:

service nginx start|stop|restart

Esto funcionó perfectamente durante tantos años, ... hasta que algunos pantalones inteligentes decidieron mejorarlos y ahora me enfrento a los sistemas Debian / Ubuntu donde el servicescript no hace nada (ya que se supone que debo usar las cosas como systemctl start nginx.service(mucho más tiempo, sin trabajo de autocompletar, ...)

Mi pregunta se refiere especialmente a Debian y Ubuntu, pero también sería útil cubrir las distribuciones de CentOS / RedHat.

Entonces, ¿hay algo que pueda salvarme de estos cambios condenados?

En caso de que no estuviera claro, estoy buscando una forma consistente de lidiar con eso, una que funcione en Debian 7.x, 8.x, la última versión de Ubuntu LTS y no LTS.

PD. Fuera del alcance de esta pregunta específica, pero se otorgan felicitaciones adicionales si la solución también cubriría la parte de habilitar y deshabilitar para los servicios.

debian systemd init.d sysvinit sorin
fuente
55
La finalización de tabulación funciona para systemctl para mí ... Y, nos guste o no, systemd es el estándar de facto ahora: también podría acostumbrarse.
jasonwryan
1
Extra: si el comando de servicio se vuelve inútil, ¿puedo eliminarlo? ¿Qué paquete lo proporciona?
sorin
3
¿No tiene sentido reemplazar el servicecomando anterior con un contenedor que llama a servicectl?
sorin
44
@jasonwryan Sí, pero también puede hacer eso , y un contenedor podría manejarlo, haciendo que la transición a systemd sea más fácil para los usuarios.
Dmitry Grigoryev
2
¿ serviceRealmente no hace nada por ti? Funciona como se esperaba en mi LMDE (que es básicamente una prueba de Debian), no pensé que fuera algo específico de LMDE. También funciona como se esperaba en mi Ubuntu VM.
terdon

Respuestas:

6

Ha habido una serie de variados sistemas de control de arranque y servicio en las plataformas Unix a lo largo de su enredada historia.

El service\chkconfigsistema basado que encontró simple y efectivo generalmente se conoce como estilo SysVinit y fue un paso importante en el camino hacia algún tipo de estandarización. Encontrará este estilo de arranque en RHEL / CentOS (EL) hasta la versión 6, Fedora hasta la 14, y en distribuciones basadas en Debian / Ubuntu hasta 2015. Sin embargo, no fue el único sistema de arranque, el estilo BSD (más simple) El sistema init todavía tiene muchos ventiladores.

SysVinit no fue una solución perfecta (¿qué es?) Y Systemd fue ideado para superar muchos de los problemas; Este es el systemctlsistema basado en comandos que está experimentando ahora. Aunque no es del agrado universal (las personas odian el cambio, la hinchazón, etc.) no hay duda de que se está convirtiendo rápidamente en el estándar de facto en la mayoría de las distribuciones.

Por lo tanto, mirando hacia adelante de inmediato la respuesta a su pregunta original es simplemente:
La norma hacia los servicios de control a través de la mayoría de las distribuciones de Linux es ahora systemctl!
Cuánto tiempo será válido esto es una incógnita; probablemente solo hasta que aparezca algo que sea mejor y sea ampliamente adoptado.

Estoy seguro de que habrá envoltorios disponibles para permitir, su favorito actual, los service/chkconfigcomandos para continuar haciendo cosas en su mayoría sensatas, pero con esta curva de aprendizaje en particular, probablemente sea mejor no luchar contra ella. Tal vez mirando hacia el futuro, por un tiempo también habrá systemctlenvoltorios para sistemas más antiguos, para hacer que administrarlos junto con los más actuales sea menos doloroso;)

DanSut
fuente
Y antes de esto era xinetd, y antes de eso era inetd
jas-
@ jas- Creo que los inetd son realmente servicios en sí mismos, creo que pueden existir en todos los sistemas de arranque. Son un tipo especial de servicio en el sentido de que proporcionan una alternativa para que otros servicios se ejecuten como servicios completos, al proporcionarlos a pedido . Sin embargo, entiendo de dónde vienes en el contexto de esta Q, solo otra forma de iniciar servicios.
DanSut
En todas las distribuciones; gentoo, centos, redhat, debian, ubuntu, etc., xinetd y anteriormente inetd consistían en un pequeño script de shell para iniciar, detener y volver a cargar configuraciones para varios servicios, pero sí, está correcto, de hecho, eran un servicio al igual que systemd.
jas-
Ubuntu usó upstart desde 6.10 y Fedora desde 9 (hasta que fueron reemplazados por systemd) upstart.ubuntu.com , y ha sido posible cambiar Debian de sysvinit durante algunos años ...
James Tocknell
5

¿No tiene sentido reemplazar el servicecomando anterior con un contenedor que llama a servicectl[sic]?

Sí, pero [...] un contenedor podría manejarlo, haciendo que la transición a systemd sea más fácil para los usuarios.

... que es, como han dicho otros en comentarios, lo que se ha hecho desde hace mucho tiempo .

El /usr/sbin/servicecomando en Debian 8 es parte del paquete sysvinit-utils. Ha estado allí desde 2009. Es una adición originada en RedHat específica de Debian para el paquete original de fuente sysvinit, y como se puede ver al leer el script reconoce tanto la ejecución del sistema como la presencia de trabajos de arranque, la generación de comandos hacia systemctly initctl( a través de sus alias) respectivamente. Esto lo ha hecho desde 2013.

service name actionestá bastante disponible incluso en sistemas operativos que no son Linux. Incluso funcionará en la mayoría de los BSD, ya que ellos también tienen sus propios servicecomandos. También hay un servicecomando shim en el paquete nosh que se traduce en . Pero …system-control action name

  • ... vaya más allá de este subconjunto común, y hay mucha menos compatibilidad por todas partes.
  • ... OpenBSD no tiene servicecomando.
  • ... los servicecomandos BSD tienen problemas bien conocidos de larga data que los administradores del sistema han estado contando historias de guerra durante décadas.

Habilitar y deshabilitar servicios es una situación similar. Aunque el chkconfigprograma SuSE (disponible empaquetado para Debian y Ubuntu) es muy diferente al de Fedora (están escritos en lenguajes de programación completamente diferentes, incluso, uno compilado, uno interpretado), hay una sintaxis mínima común , con acción siendo o . Pero …chkconfig name actiononoff

  • ... de nuevo, más allá de este subconjunto común, hay menos compatibilidad.
  • ... no hay es chkconfigen los BSD, ya que las herramientas convencionales para esto son bien sysrco el más reciente de OpenBSD rcctl enabley rcctl disable. Hay chkconfigy rcctlcuñas en el paquete nosh que se traducen en y .system-control enable namesystem-control disable name
  • ... solo Fedora chkconfigsabe acerca de systemd y actúa como un calce para systemctl enabley systemctl disable. El SuSE chkconfigno tiene conocimiento de systemd.

Otras lecturas

JdeBP
fuente
2

No hay una forma estándar de iniciar y detener servicios en Linux.

¿Hay algo que pueda salvarme de estos cambios condenados?

Pruebe la herramienta de gestión / configuración de configuración: Ansible , Chef , Saltstack , Puppet o lo que sea.

Puede iniciar y habilitar un servicio con Ansible:

ansible all -i inv -m service -a 'name=service-name state=started enabled=true'

Eche un vistazo a la clase LinuxService en el servicemódulo de Ansible :

Esta es la clase de manipulación del servicio Linux: actualmente admite una combinación de archivos binarios y scripts de inicio para controlar los servicios iniciados en el arranque, así como para controlar el estado actual.

Evgeny Vereshchagin
fuente
De alguna manera parece que los chicos de Ubuntu pudieron mantener el script de servicio funcionando después de cambiar a systemd. Mirando hacia adentro parece ser lo suficientemente inteligente como para usar el backend correcto. No puedo decir lo mismo sobre Debian.
sorin
@sorin, bueno, service (8): use systemctl en máquinas que ejecutan systemd . Pero cuando ejecutamos "service foo stop" y foo resulta ser un servicio que tiene uno o más archivos .socket, también detenemos las unidades .socket . ¿Está bien?
Evgeny Vereshchagin
@sorin, también La acción de recarga vuelve a la secuencia de comandos de inicio sysv en caso de que el archivo de servicio systemd (todavía) no admita la recarga para un servicio específico. . ¿Está bien?
Evgeny Vereshchagin
1

Su problema es que Debian / Ubuntu han cambiado a lo nuevo systemdcomo reemplazo de lo viejo sysvinit. Pregunte cuál es mejor y comenzará una guerra de llamas, pero siempre puede volver a la anterior sysvinit, verifique esto si desea volver.

YoMismo
fuente