4.1.2.2. Consulta¶
Trataremos aquí el modo en que podemos cónocer con systemd el estado de nuestros servicios. Tanto esto, como la manipulación se hacen a través del comando systemctl.
Para conocer todas las unidades que systemd gestiona basta con:
$ systemctl list-unit-files
UNIT FILE STATE
[...]
console-getty.service disabled
console-shell.service disabled
container-getty@.service static
cron.service enabled
cryptdisks-early.service masked
[...]
La orden muestra el fichero que representa a la unidad y cuál es su estado de configuración. Es importante entender que este estado se refiere al modo en que se ha configurado la unidad en el sistema y no al estado de funcionamiento, ya que una unidad puede haberse habilitado, pero no estar funcionando, porque ha fallado. Algunos de los estados posibles son:
- enabled
La unidad se habilitó explícitamente.
- static
La unidad no se puede habilitar o deshabilitar. Hay casos en que no tiene sentido, como por ejemplo, cuando la unidad representa un runlevel.
- disabled
La unidad se encuentra deshabilitada.
- masked
La unidad se encuentra más que deshabilitada, para evitar que, aunque por error se habilite, no pueda arrancarse ni manual ni automáticamente.
El otro concepto que cita sin definir exactamente es el de unidad. Hay 12 tipos de unidades, aunque los dos más habituales son:
- service
Que es una unidad que representa un servicio.
- target
Que representa un conjunto de unidades relacionadas entre sí. La carga de una unidad de este tipo, implica la carga de todas las unidades que contiene. Si se quiere conocer qué unidades supone la carga de un target basta con:
$ systemctl list-dependencies basic.target
siendo en este caso basic.target la unidad target de la que queremos conocer la información.
Si desea mostrarse en el listado un sólo tipo de unidad, podemos hacer:
$ systemctl list-unit-files --type=target
En cambio, si nuestra intención es comprobar cuál es el estado de funcionamiento de las unidades, entonces debe ejecutarse:
$ systemctl list-units
UNIT LOAD ACTIVE SUB DESCRIPTION
[...]
home.mount loaded active mounted /home
[...]
En realidad, si se ejecuta systemctl sin argumento alguno se obtiene
esta misma salida. En la salida podemos comprobar que la unidad se cargó
(loaded) y que está activa (activa). Como en el caso anterior, puede
filtrarse por tipo de unidad (con --type
), y también por estado, lo cual es
bastante util para detectar problemas:
$ systemctl list-units --state=failed
list-units no detecta unidades inactivas. Para un listado más completo
puede añadirse la opción --all
(de hecho, si queremos consultar
las que están inactivas con --state
), no habrá otra manera:
$ system list-units --state=inactive --all
Nota
No obstante, a pesar de incluir esta última opción, habrá unidades que sigan sin salir, puesto que list-units sólo muestra las unidades que systemd ha leído y procesado, porque considera que en algún momento tendrá que usarlas. En esto se diferencia de list-unit-files que sí las muestra todas.
Hasta hemos visto cómo listar unidades, pero también se puede consultar el estado de una unidad en particular:
$ systemctl status rsyslog.service
● rsyslog.service - System Logging Service
Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled)
Active: active (running) since sáb 2016-11-26 18:44:36 CET; 2h 40min ago
Docs: man:rsyslogd(8)
http://www.rsyslog.com/doc/
Main PID: 494 (rsyslogd)
CGroup: /system.slice/rsyslog.service
└─494 /usr/sbin/rsyslogd -n
También se puede preguntar por el estado mediante los argumentos is-enabled, is-active e is-failed. Debe tenerse en cuenta que el primer argumento, hace referencia a la configuración (como list-unit-files), y los otros dos al estado en sí:
$ systemctl is-active rsyslog.service
active
Debe notarse que la orden devuelve 0 o un valor distinto dependiendo de si la respuesta es afirmativa o no.
POr último, puede ser también interesante conocer cuáles han sido los tiempos de arranque. El tiempo total puede conocerse con:
$ systemd-analyze time
Y el tiempo particular de arranque de cada servicio:
$ systemd-analyze blame