☰

¿Cómo es responsable de mostrar "Iniciando... [ok]"

tag-icon • tag-icon linux daemon
¿Cómo es responsable de mostrar "Iniciando... [ok]"

Cuando inicio un servicio como:

root@foo [~]# service foobar stop
Stopping Foobar:                                       [  OK  ]

Puedo ver un indicador de estado: [ OK ]que es diferente del visible en /var/log/boot.log:

[  OK  ] Started LSB: disk temperature monitoring daemon.
...

O incluso diferente de:

* /proc is already mounted
* Caching service dependencies ...        [ ok ]

En estos tres ejemplos, ¿qué proceso es responsable de mostrar e iniciar los demonios? Dicho de otra manera, ¿ qué biblioteca se utiliza para mostrar [ OK ]?[FAILED]

Respuesta1

Cuando una invocación manual serviceejecuta un script de estilo SysV desde /etc/init.d o /etc/rc.d, toda la salida de estado dependeenteramente en ese guión.

Los scripts init.d correctamente escritos utilizarán una biblioteca de funciones de shell proporcionadas por la distribución. Por ejemplo, en Debian, la mayoría de los scripts cargarán (generarán) el archivo /lib/lsb/init-functionsy simplemente llamarán a las funciones proporcionadas de esta manera:

caso "$1" en
  comenzar)
    log_daemon_msg"Iniciando $DESC" "$NAME"
    hacer_iniciar
    caso "$?" en
        0|1)log_end_msg0 ;;
        2) log_end_msg 1;;
    esac
    ;;
  [...]
esac

Aquí esta lalista de funciones estándardefinido por LSB. (Tenga en cuenta que las distribuciones pueden proporcionaradicionalfunciona más allá del estándar, como en el ejemplo anterior. También tenga en cuenta que, por ejemplo, OpenRC o Arch Linuxno lo sonCompatible con LSB y utiliza estilos completamente diferentes).

De hecho, algunas distribuciones también proporcionarán este código repetitivo de forma centralizada, y todo lo que le queda al script init.d es implementar do_start. (Vea OpenRC de Gentoo y Debian /lib/init/init-d-scriptcomo ejemplos). Sin embargo, esa no es una característica LSB "estándar": los scripts que intentan ser compatibles con LSB aún tienen que hacerlo manualmente.

Nota:Hago hincapié en "Escrito correctamente" porque realmente no hay nada quefuerzaun script init.d para utilizar estas funciones, además de la supervisión humana. Si el script quiere informar el estado de forma simple echo(o vía cowsay), siempre puede hacerlo. Esto es especialmente un problema con el software comercial distribuido fuera de los canales normales: su estado de salidanuncase ve bastante bien (y, francamente, todo el script init.d nunca se comporta del todo bien).

Mientras tanto, cuando se llaman scripts SysV durante elproceso de arranque, el resultado depende aún más de la distribución: a veces verá resultados directamente desde los propios scripts, pero a veces el sistema de inicio "principal" proporcionará su propio resultado de estado para todos los servicios que inicie. (Ejemplo:Los antiguos scripts de inicio de Arch Linux, al iniciar un servicio en segundo plano).

Pero tu segundo ejemplo es en realidadnoun inicio de estilo SysV: es systemd (que resulta que está iniciando un script init.d 'heredado' en su ejemplo). Systemd es un administrador de servicios completo que utiliza configuraciones de servicios (no scripts) y, por lo tanto,todoLa salida del estado de arranque/apagado la proporciona el propio systemd. Esto también se aplica a la mayoría de los demás "administradores de servicios", incluidos init-ng, SMF o Upstart.

Respuesta2

Esto proviene de scripts de inicio que dependen de la distribución. Verifique el contenido del serviceprograma, probablemente se trate de algún script de shell que invoque scripts de administración subyacentes (ahora se consideran obsoletos los SysV) o binarios (systemd es el camino a seguir). Esta es una de las ventajas de systemd: no obtendrá respuestas de "eso depende".

información relacionada