Читать книгу: «Raspberry Pi® a fondo para desarrolladores», страница 7

Capítulo

3

Exploración de sistemas Linux empotrados

Este capítulo presenta los conceptos, comandos y herramientas esenciales para manejar con eficiencia el sistema Linux empotrado en el Raspberry Pi. La primera parte de este capítulo es descriptiva. Explica los aspectos básicos de Linux en sistemas empotrados y del proceso de inicio de Linux. Después aprenderemos a gestionar los sistemas Linux paso a paso. Para este ejercicio es muy recomendable abrir una conexión terminal con nuestro Raspberry Pi, o bien una ventana de terminal en el propio RPi, antes de continuar. Luego, en el capítulo se describe el sistema de gestión de versiones de código fuente Git. Se trata de un tema importante porque los ejemplos de código fuente de este libro se distribuyen a través de GitHub. La virtualización de escritorios se describe igualmente, puesto que resultará útil para el desarrollo multiplataforma en posteriores capítulos. El capítulo finaliza describiendo cómo descargar los ejemplos de código fuente para este libro.

Materiales necesarios para este capítulo:

❏Cualquier modelo de Raspberry Pi con una conexión terminal (véase el capítulo 2, "El software del Raspberry Pi") o una ventana de terminal, preferiblemente ejecutando Raspbian.

Puede encontrar más detalles sobre este capítulo en la dirección:

www.exploringrpi.com/chapter3/.

Introducción a Linux para sistemas empotrados

Lo primero es lo primero: aun cuando la expresión "Linux empotrado" (embedded Linux) está presente ya en el título del capítulo, ¡no hay nada que pueda denominarse "Linux empotrado"! No existe una versión especial del núcleo de Linux para sistemas empotrados: es el mismo núcleo estándar de Linux el que se ejecuta en dichos sistemas. Dicho esto, lo cierto es que la expresión Linux empotrado resulta de uso común y está ampliamente aceptada. Así pues, este libro utiliza "Linux empotrado" en lugar de "Linux ejecutándose en un sistema empotrado", que sería más correcta.

La palabra "empotrado" (embedded) sirve para indicar la presencia de un sistema hardware empotrado (embedded system), concepto que se puede definir libremente como un tipo de hardware con software integrado, diseñado específicamente para una determinada aplicación. Es un concepto que contrasta vivamente con el de ordenador personal (PC), que es una plataforma de computación de propósito general diseñada para ejecutar una infinidad de aplicaciones diferentes, tales como navegadores de Internet, procesadores de texto o videojuegos. Ahora bien, la línea que separa unos sistemas de otros se va difuminando progresivamente. Sin ir más lejos, el Raspberry Pi puede actuar de las dos maneras, y son muchos los usuarios que deciden emplearlo exclusivamente como ordenador personal bastante capaz, o bien como dispositivo multimedia. Sin embargo, los sistemas empotrados presentan algunas características diferenciadoras:

❏Suelen incluir aplicaciones específicas y dedicadas a tareas concretas.

❏Su capacidad de procesamiento, memoria y almacenamiento son a menudo limitadas.

❏En general forman parte de sistemas más grandes que suelen estar conectados a sensores y actuadores externos.

❏A menudo desempeñan su labor en sistemas para los cuales la fiabilidad es un elemento crucial, como controles en automóviles, aviones y equipos médicos.

❏Operan muchas veces en tiempo real, es decir, donde sus salidas están relacionadas directamente con las entradas presentes, por ejemplo en sistemas de control.

Los sistemas empotrados se encuentran en todas partes. Como ejemplos podemos citar: máquinas de vending, aplicaciones para el hogar, teléfonos, smartphones, cadenas de fabricación y ensamblaje, televisiones, consolas de videojuegos, automóviles (por ejemplo, la dirección asistida o los sensores de aparcamiento), elementos de red (como switches, routers o puntos de acceso inalámbricos), sistemas de sonido, equipos médicos, impresoras, controles de acceso a edificios, parquímetros, sistemas de control de agua y energía, relojes, herramientas de construcción, cámaras digitales, monitores, tabletas, lectores de libros digitales, robots, sistemas de pago inteligentes, etc.

La gran proliferación de dispositivos con Linux empotrado se debe, en parte, a la rápida evolución de la tecnología smartphone, que ha presionado a la baja los precios de los microprocesadores con tecnología ARM. ARM Holdings PLC es la compañía británica que comercializa, para los modelos del RPi, las licencias de uso de los diseños ARMv6 y ARMv7 por una cantidad aproximada de entre el 1 y el 2% del precio real de venta del procesador. Avago Technologies Ltd., la propietaria de Broadcom Corporation desde mayo de 2015, no comercializa en la actualidad procesadores directamente a minoristas, pero sus microprocesadores similares a los BCM2835/6/7 tienen un precio de venta de entre 5 y 10 dólares.

Ventajas y desventajas de Linux para sistemas empotrados

Hay muchos tipos de plataformas empotradas, cada una con sus propias ventajas e inconvenientes. Las hay con un coste muy bajo para pedidos de gran volumen, por debajo de 1 euro, por ejemplo Amtel AVR (8/16 bits), Microchip PIC o TI Stellaris, pero también muy caras y especializadas que pueden llegar hasta los 150 euros, como microprocesadores de señales digitales (DSP, Digital Signal Processor) multinúcleo. Generalmente, dichas plataformas se programan en lenguajes C o ensamblador (assembly language), lo que exige un conocimiento muy solvente de los detalles hardware de más bajo nivel de las arquitecturas antes de empezar siquiera a plantearse el desarrollo de aplicaciones útiles. Linux empotrado ofrece una alternativa a tales plataformas en el sentido de que elimina la exigencia de conocer al detalle la arquitectura subyacente del sistema para emprender el desarrollo de aplicaciones. Ahora bien, si nuestras aplicaciones van a tener que comunicarse a bajo nivel con dispositivos electrónicos, sí que será necesario un cierto conocimiento de las arquitecturas.

Veamos algunas de las razones por las que Linux empotrado ha experimentado un crecimiento tan reseñable:

❏Linux es un sistema operativo (SO) eficiente y escalable que se ejecuta sobre una amplia variedad de dispositivos, desde los de coste más bajo, orientados al gran consumo, hasta los servidores más grandes y caros. Asimismo, ha evolucionado con el correr del tiempo desde la época en que los ordenadores tenían una mínima fracción de la potencia que ofrecen ahora, pero conservando casi intacta su eficiencia.

❏Existe un inmenso conjunto de aplicaciones y herramientas de código abierto, listas para su instalación y uso en un sistema empotrado. Si necesitamos, por ejemplo, un servidor web para nuestra aplicación empotrada, podremos usar el mismo que instalaríamos en un servidor Linux.

❏Existen excelentes controladores de código abierto para una gran variedad de periféricos y dispositivos, desde adaptadores de red hasta monitores.

❏Linux es un sistema de código abierto y no hay que pagar nada por usarlo.

❏Su núcleo y sus aplicaciones se ejecutan a diario en una cantidad tal de sistemas por todo el mundo que los errores son extremadamente infrecuentes y además se detectan y corrigen rápidamente.

Una desventaja de Linux empotrado es su falta de idoneidad para las aplicaciones en tiempo real debido a la sobrecarga, fundamentalmente de tiempo en este caso, del propio SO. Así pues, para aplicaciones de gran precisión y mínima latencia, como el procesamiento de señales analógicas, Linux empotrado podría no ser la solución perfecta. Sin embargo, incluso en aplicaciones de tiempo real, se emplea a menudo como cerebro e interfaz de control dentro de un conjunto interconectado de sensores (véase el capítulo 12). Además, el desarrollo de las capacidades de Linux RTOS (Real Time Operating Systems, sistemas operativos de tiempo real) continúa avanzando y progresa en su objetivo de agilizar las interrupciones del SO para su uso en tiempo real.

¿Es Linux gratuito y de código abierto?

Linux se publica bajo licencia GNU GPL (General Public License, licencia pública general), que garantiza a los usuarios el derecho de uso y modificación del código fuente sin límites. Así pues, la palabra free hace aquí más referencia al concepto de "libre" que al de "gratuito" (ambos son significados del término en inglés). De hecho, algunas de las distribuciones de Linux más caras son precisamente las destinadas a las arquitecturas empotradas. Podrá encontrar una guía rápida para familiarizarse con la licencia GPLv3 en la web www.gnu.org, que relaciona nuestros derechos como usuarios (Smith, 2013):

Derecho a utilizar el software para cualquier propósito.

Derecho a modificar el software para que se ajuste a sus necesidades.

Derecho a compartir el software con amigos y vecinos.

Y derecho a compartir todos aquellos cambios que introduzca en él.

Aun si estamos utilizando una distribución descargada de forma gratuita, puede que nos cueste un esfuerzo significativo modificar las librerías y los controladores de dispositivo para adaptar los componentes y módulos particulares que deseemos utilizar en el desarrollo de los productos.

Cómo iniciar el Raspberry Pi

Lo primero que deberíamos ver cuando arrancamos un ordenador es la UEFI (Unified Extensible Firmware Interface, interfaz de firmware ampliable unificada), que brinda compatibilidad con las rutinas de servicio de la antigua BIOS (Basic Input/Output System, sitema básico de entrada/salida). La pantalla de inicio muestra información del sistema y nos invita a pulsar una tecla para modificar estos ajustes. La UEFI comprueba los componentes del hardware, como la memoria, y, luego, carga el SO, generalmente desde una unidad de disco duro SSD (Solid State Disk, disco de estado sólido). Así pues, cuando encendemos un ordenador, la UEFI, o la BIOS, ejecutan las tareas siguientes:

1. Toma el control del procesador del equipo.

2. Inicializa y comprueba los componentes hardware.

3. Carga el SO desde la unidad SSD o disco duro convencional.

La UEFI/BIOS ofrece una capa de abstracción que permite al SO interaccionar con la pantalla y otros periféricos de entrada/salida del sistema, como ratón, teclado y almacenamiento externo. Sus ajustes se guardan en una memoria flash NAND alimentada por una pila de botón (que se puede ver en las placas madre de los ordenadores) que alimenta también el reloj del sistema.

Los gestores de arranque del Raspberry Pi

Como la mayoría de los dispositivos Linux empotrados, el RPi carece de BIOS y de batería de alimentación, al menos de forma predeterminada (veremos cómo se añade un reloj en tiempo real al RPi en el capítulo 9). En lugar de eso, utiliza una combinación de gestores de arranque (bootloaders). Generalmente, los gestores de arranque son pequeños programas que realizan la función crítica de vincular el hardware concreto de cada placa con Linux:

❏Inicializan los controladores (memoria, gráficos, E/S).

❏Preparan y asignan la memoria del sistema para el SO.

❏Localizan el SO y preparan su carga.

❏Cargan el SO y le pasan el control.

El gestor de arranque de Linux empotrado es un programa personalizado para cada tipo de placa, incluido el RPi. Existen gestores de arranque de código abierto para Linux, tales como Das U-Boot (el cargador universal de referencia), que se puede personalizar, siempre que se cuente con un conocimiento detallado del hardware de la plataforma de Linux empotrado, mediante parches de software específicos de cada plataforma (diríjase a tiny.cc/erpi301). El RPi utiliza un enfoque distinto: utiliza unos gestores de arranque muy eficientes pero de código cerrado, desarrollados específicamente para el RPi por Broadcom. Tanto el gestor de arranque como los archivos de configuración se encuentran en el directorio /boot de la imagen en el RPi:

pi@erpi /boot $ ls -l *.bin start.elf *.txt *.img fixup.dat

-rwxr-xr-x 1 root root 17900 Jun 16 01:57 bootcode.bin

-rwxr-xr-x 1 root root 120 May 6 23:23 cmdline.txt

-rwxr-xr-x 1 root root 1581 May 30 14:49 config.txt

-rwxr-xr-x 1 root root 6174 Jun 16 01:57 fixup.dat

-rwxr-xr-x 1 root root 137 May 7 00:31 issue.txt

-rwxr-xr-x 1 root root 3943888 Jun 16 01:57 kernel7.img

-rwxr-xr-x 1 root root 3987132 Jun 16 01:57 kernel.img

-rwxr-xr-x 1 root root 2684312 Jun 16 01:57 start.elf

La figura 3-1 ilustra el proceso de arranque en el RPi, donde cada etapa del mismo se carga e invoca por la precedente. Los archivos bootcode.bin y tart.elf son gestores de arranque de código cerrado que están en código binario y se ejecutan en la GPU del RPi, y no en la propia CPU. El archivo de licencia que podemos encontrar en github.com/raspberrypi/firmware/tree/master/boot indica que se autoriza la redistribución "en código binario, sin modificaciones" y que "solo se puede utilizar con propósitos de desarrollo y ejecución en un dispositivo Raspberry Pi". Podemos encontrar una imagen comprimida del núcleo en /boot/kernel.img. Por descontado, es código abierto.

La salida que sigue es una secuencia de arranque típica, capturada con el cable serie USB a TTL de 3,3 V que vimos en el capítulo 1. El cable estaba fijo a los pines 6 (GND), 8 (UART_TXD) y 10 (UART_RXD) de la cabecera del RPi, y los datos se capturaron a 115.200 baudios. A diferencia de los gestores U-boot, que se ejecutan en la CPU, los gestores tempranos del RPi no ofrecen salida por consola, aunque sí hacen parpadear los LED de la placa con patrones específicos si surgen problemas. Lo que sigue es un extracto de la salida por consola durante el arranque del RPi 3. Muestra una importante información del sistema, como el mapeo de la memoria:

Figura 3-1: La secuencia de arranque completa en el RPi.

Uncompressing Linux... done, booting the kernel.

[ 0.000000] Booting Linux on physical CPU 0x0

...

[ 0.000000] Linux version 4.1.18-v7+ (dc4@dc4-XPS13-9333) (gcc version

4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #846 SMP Thu Feb

25 14:22:53 GMT 2016

[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7) ...

[ 0.000000] Machine model: Raspberry Pi 3 Model B Rev 1.2

[ 0.000000] cma: Reserved 8 MiB at 0x36400000 ...

[ 0.000000] Kernel command line: 8250.nr_uarts=1 dma.dmachans=0x7f35

bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa02082

bcm2709.serial=0xbbffd b2c smsc95xx.macaddr=B8:27:EB:FF:DB:2C

bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000

vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyS0,115200

root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

[ 0.000000] Memory: 874456K/901120K available (6024K kernel code, 534K

rwdata, 1660K rodata, 448K init, 757K bss, 18472K reserved, 8192K cma-

reserved)

[ 0.000000] Virtual kernel memory layout:

vector : 0xffff0000 - 0xffff1000 ( 4 kB)

fixmap : 0xffc00000 - 0xfff00000 (3072 kB)

vmalloc : 0xb7800000 - 0xff000000 (1144 MB)

lowmem : 0x80000000 - 0xb7000000 ( 880 MB)

modules : 0x7f000000 - 0x80000000 ( 16 MB)

.text : 0x80008000 - 0x807895a0 (7686 kB)

.init : 0x8078a000 - 0x807fa000 ( 448 kB)

.data : 0x807fa000 - 0x8087fac0 ( 535 kB)

.bss : 0x80882000 - 0x8093f79c ( 758 kB)

...

[ 0.052103] Brought up 4 CPUs

[ 0.052201] SMP: Total of 4 processors activated (153.60 BogoMIPS).

[ 0.052231] CPU: All CPU(s) started in HYP mode. ...

[ 1.467927] console [ttyS0] enabled

...

[ 3.307558] systemd[1]: Detected architecture 'arm'.

[ 3.321650] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at

usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:ff:db:2c

[ 3.488061] NET: Registered protocol family 10

[ 3.498204] systemd[1]: Inserted module 'ipv6'

[ 3.510056] systemd[1]: Set hostname to <erpi> ...

[ 5.450070] spi spi0.0: setting up native-CS0 as GPIO 8

[ 5.450453] spi spi0.1: setting up native-CS1 as GPIO 7 ...

...

Raspbian GNU/Linux 8 erpi ttyS0

erpi login:

Obtenemos la misma información si escribimos dmesg|more en una ventana de terminal. No es difícil ver cómo se configura el estado inicial del hardware, pero la mayoría de las entradas se antojan enigmáticas por el momento. Hay algunos puntos importantes que observar, como se pueden ver destacados en la salida anterior:

❏El núcleo de Linux se descomprime en memoria y, luego, se inicia. El ARMv7 del RPi 2/3 (kernel7.img) y el ARMv6 del RPi/RPi B+ (kernel.img) utilizan una versión ligeramente diferente del núcleo.

❏Se identifica la versión del núcleo de Linux, por ejemplo 4.1.18-v7+.

❏El modelo de la máquina se identifica de manera que se pueda cargar el árbol de código binario correcto.

❏La dirección de red MAC (Medium Access Control, control de acceso al medio (físico)), una dirección hardware única que identifica el dispositivo en la red a nivel físico) se pasa como un argumento del núcleo en la línea de comandos. La dirección MAC se establece automáticamente en el RPi mediante los tres últimos bytes del número de serie de la CPU, que se fija durante la fabricación. Ejecute cat /proc/cpuinfo para mostrar el número de serie de la placa. En este caso, el número es 00000000bbffdb2c, donde ffdb2c sirve para facilitar un número de dirección MAC único.

❏El usuario puede configurar algunos de los argumentos del núcleo restantes editando el archivo cmdline.txt, por ejemplo ejecutando sudo nano cmdline.txt del siguiente modo:

pi@erpi /boot $ more cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2

rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

❏Se muestra el formato de la memoria virtual del núcleo. La entrada de los módulos es particularmente importante y se utilizará en el capítulo 8.

El principal archivo de configuración del RPi es /boot/config.txt. Los cambios que introducimos mediante la herramienta raspi-config se reflejan en este archivo. Es posible editarlo ejecutando sudo nano /boot/config.txt para habilitar y deshabilitar el bus hardware, elevar la frecuencia del procesador, etc.

pi@erpi /boot $ more config.txt

# For more options and information see

# http://www.raspberrypi.org/documentation/configuration/config-txt.md ...

# Uncomment some or all of these to enable the optional hardware interfaces

dtparam=i2c_arm=on

#dtparam=i2s=on

dtparam=spi=on

...

# Additional overlays and parameters are documented /boot/overlays/README

El gestor de arranque del RPi utiliza un archivo de configuración para la tarjeta llamado device tree o árbol de dispositivos (también llamado device tree binary, árbol de dispositivos binario) que contiene la información específica requerida por el núcleo para arrancar el RPi. Este archivo contiene toda la información necesaria para describir el tamaño de la memoria, la velocidad del reloj, los dispositivos de la placa, etc. Este árbol de dispositivos binario o DTB, donde "binario" hace aquí referencia al archivo compilado, se crea a partir del árbol de dispositivos fuente o DTS (Device Tree Source), que es, obviamente, el archivo de código fuente a partir del que se obtiene dicho binario compilando con el DTC (Device Tree Compiler). Este tema se trata en profundidad en el capítulo 8. El directorio /boot contiene los binarios del árbol de dispositivos para los distintos modelos de RPi:

pi@erpi /boot $ ls -l *.dtb

-rwxr-xr-x 1 root root 10841 Feb 25 23:22 bcm2708-rpi-b.dtb

-rwxr-xr-x 1 root root 11120 Feb 25 23:22 bcm2708-rpi-b-plus.dtb

-rwxr-xr-x 1 root root 10871 Feb 25 23:22 bcm2708-rpi-cm.dtb

-rwxr-xr-x 1 root root 12108 Feb 25 23:22 bcm2709-rpi-2-b.dtb

-rwxr-xr-x 1 root root 12575 Feb 25 23:22 bcm2710-rpi-3-b.dtb

El código fuente de estos DTB se encuentra disponible en formato DTS. Los archivos DTS de cada modelo de RPi presentan una sintaxis similar al extracto siguiente, que detalla el hardware de los pines de los LED incorporados a la placa y de uno de los dos buses I2C del RPi 2:

&i2c1 {

pinctrl-names = "default";

pinctrl-0 = <&i2c1_pins>;

clock-frequency = <100000>;

};

&leds {

act_led: act {

label = "led0";

linux,default-trigger = "mmc0";

gpios = <&gpio 47 0>;

};

pwr_led: pwr {

label = "led1";

linux,default-trigger = "input";

gpios = <&gpio 35 0>;

};

};

El código fuente completo del archivo DTS para el RPi 2 (bcm2709-rpi-2-b.dts) está disponible en: tiny.cc/erpi302. Se pueden añadir al RPi archivos binarios del árbol de dispositivos adicionales, como sensores, placas HAT y pantallas LCD:

pi@erpi /boot/overlays $ ls

ads7846-overlay.dtb i2s-mmap-overlay.dtb pps-gpio-overlay.dtb ...

hifiberry-amp-overlay.dtb mcp2515-can0-overlay.dtb rpi-proto-overlay.dtb

hy28b-overlay.dtb piscreen-overlay.dtb w1-gpio-pullup-overlay.dtb

i2c-rtc-overlay.dtb pitft28-resistive-overlay.dtb

La descripción completa del código fuente del árbol de dispositivos para la distribución del RPi está en el código fuente del resto del libro en el directorio /chp03/dts.

Espacio del núcleo y espacio de usuario

El núcleo de Linux se ejecuta en una área de la memoria del sistema llamada espacio del núcleo (kernel space), mientras que, por su parte, las aplicaciones normales se ejecutan en el espacio de usuario (user space). Una separación estricta entre ambos espacios en memoria evita que las aplicaciones de usuario accedan al espacio y los recursos requeridos para el funcionamiento del núcleo de Linux. Esto ayuda a evitar que el núcleo se cuelgue a causa del código de usuario mal desarrollado, así como que las aplicaciones de un usuario interfieran en la ejecución de las aplicaciones de otro e invadan su espacio. También proporcionan un grado más elevado de seguridad.

El núcleo de Linux es "propietario" y tiene acceso pleno a toda la memoria física y al resto de los recursos del RPi. Así pues, debemos ser muy cuidadosos y solo permitir que el código más estable y comprobado se ejecute en el espacio del núcleo. Puede observar las arquitecturas e interfaces ilustradas en la figura 3-2, donde las aplicaciones de usuario emplean la librería GNU C (glibc) para comunicarse con la interfaz de llamadas del núcleo del sistema. Luego, los servicios del núcleo se ponen a disposición del espacio de usuario de manera controlada mediante el uso de llamadas del sistema.

Figura 3-2: Las arquitecturas del espacio de usuario y del espacio del núcleo de Linux.

Un módulo del núcleo (kernel module) es un archivo objeto que contiene código binario y que se puede cargar y descargar del núcleo bajo demanda. En muchos casos, el núcleo puede incluso cargar y descargar módulos mientras se está ejecutando, es decir, "en caliente", sin necesidad de reiniciar el RPi. Por ejemplo, si enchufamos un adaptador WiFi USB en el RPi, es posible que el núcleo utilice un LKM (Loadable Kernel Module o módulo cargable del núcleo) para hacerlo funcionar. Sin esta capacidad modular, el núcleo de Linux sería extremadamente grande, puesto que tendría que dar soporte a todos los controladores que el RPi pudiera llegar a necesitar. Asimismo, tendríamos que recompilar el núcleo cada vez que quisiéramos añadir un nuevo hardware. Una desventaja de los LKM es que los archivos de controlador se deben mantener para cada dispositivo. La interacción con los LKM se describe a lo largo de todo el libro, y en el capítulo 16 veremos cómo escribir nuestros propios LKM.

Como se indica en la figura 3-1, las etapas del gestor de arranque (bootloader stages) ceden el control al núcleo después de que este haya finalizado su descompresión en la memoria. Después, el núcleo monta el sistema de archivos raíz. El último paso del núcleo durante el proceso de arranque es la llamada a systemd init (/sbin/init en un RPi con Raspbian Jessie), que es el primer proceso de usuario que se inicia, y también el siguiente tema que vamos a tratar.

El gestor de sistema y servicios systemd

Un gestor de sistema y servicios (system and service manager) inicia y detiene servicios (por ejemplo, servidores web, servidor SSH) dependiendo del estado actual del RPi, es decir, si se está iniciando, apagando, etc. El gestor de sistema

y servicios systemd se ha añadido recientemente, y no sin controversia, a Linux y tiene como objetivo sustituir al gestor System V (SysV) init, al tiempo que mantiene la compatibilidad hacia atrás. Una desventaja grave de SysV init es que inicia los servicios en serie, es decir, que espera a que una tarea finalice antes de comenzar la siguiente, lo que puede alargar el tiempo de arranque del dispositivo. El gestor systemd está activado de forma predeterminada en Debian 8/Raspbian 8 (Jessie) y permite iniciar los servicios del sistema en paralelo, lo que reduce, obviamente, los tiempos de arranque, sobre todo en procesadores multinúcleo como los de los RPi 2/3. De hecho, podemos mostrar la duración de dicho proceso del siguiente modo:

pi@erpi ~ $ systemctl --version

systemd 215 +PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT

+ACL +XZ -SECCOMP -APPARMOR

pi@erpi ~ $ systemd-analyze time

Startup finished in 2.230s (kernel) + 6.779s (userspace) = 9.009s

ADVERTENCIA Si observa el mensaje “command not found” (comando no encontrado) en este punto, lo más probable es que esté usando una distribución Raspbian 7, que emplea SysV init. Para más información, visite la página web de este capítulo: www.exploringrpi.com/chapter3/.

Además de ser un gestor de sistema y servicios, systemd incluye software para gestión de inicios de sesión, archivos de log, gestión de dispositivos, sincronización de tiempos, etc. Los críticos de systemd insisten en que su proyecto de desarrollo ha traspasado sus propios límites y ha ido invadiendo áreas alejadas de su propósito fundamental. Hasta cierto punto, esta invasión de otras áreas ha supuesto que systemd resulte ahora básico para el futuro del propio Linux, hasta el punto de eliminar las posibilidades de elegir de los propios usuarios. Sin embargo, parece claro que systemd goza de una amplia aceptación por parte de las distribuciones Linux y que está aquí para quedarse.

Podemos utilizar el comando systemctl para inspeccionar y controlar el estado de systemd. Si lo invocamos sin argumentos, nos ofrecerá una lista completa de servicios en ejecución en el RPi (para pasar a otra pantalla, pulse la barra espaciadora, y para salir, Q):

pi@erpi ~ $ systemctl

networking.service loaded active exited LSB: Raise network interfaces

ntp.service loaded active running LSB: Start NTP daemon

serial-getty@ttyAMA0 loaded active running Serial Getty on ttyAMA0

ssh.service loaded active running OpenBSD Secure Shell server

getty.target loaded active active Login Prompts ...

El comando systemd uses archivos de servicio (service files), que presentan una extensión service, para definir el comportamiento de los diferentes servicios durante su inicio, apagado, recarga, etc. Véase el directorio /lib/systemd/system.

El servicio del protocolo NTP (Network Time Protocol, protocolo de tiempo de red) se ejecuta por defecto con la propia instalación. El gestor systemd sirve para manejar tales servicios en el RPi. Por ejemplo, podemos identificar el número exacto del servicio y obtener su estado actual del siguiente modo:

pi@erpi:~$ systemctl list-units -t service | grep ntp

ntp.service loaded active running LSB: Start NTP daemon

pi@erpi:~$ systemctl status ntp.service

• ntp.service - LSB: Start NTP daemon

Loaded: loaded (/etc/init.d/ntp)

Active: active (running) since Mon 2016-01-02 13:00:48 GMT; 2h 21min ago

Process: 502 ExecStart=/etc/init.d/ntp start (code=exited, status=0/ SUCCESS)

CGroup: /system.slice/ntp.service

├─552 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 107:112

└─559 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 107:112

Podemos detener el servicio ntp con el comando systemctl, momento a partir del que dejará de actualizar el reloj con el tiempo de la red.

pi@erpi:~$ sudo systemctl stop ntp

pi@erpi:~$ systemctl status ntp

• ntp.service - LSB: Start NTP daemon

Loaded: loaded (/etc/init.d/ntp)

Active: inactive (dead) since Mon 2017-01-02 17:42:26 GMT; 6s ago

Process: 1031 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)

Process: 502 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)

Para reiniciar el servicio, ejecutamos:

pi@erpi ~ $ sudo systemctl start ntp

La tabla 3-1 ofrece un resumen de los comandos de systemd con la sintaxis del servicio ntp como ejemplo. Muchos de estos comandos exigen elevación a permisos de superusuario con el uso de sudo, como veremos en la sección siguiente.

Tabla 3-1: Comandos habituales de systemd.

El nivel de ejecución (runlevel) describe el estado actual del RPi y se puede utilizar para controlar los procesos o servicios iniciados por el sistema init. Bajo SysV hay diferentes niveles de ejecución, identificados como 0 (halt), 1 (single-user mode), 2 a 5 (multi-user modes), 6 (reboot) y S (start-up). Cuando el proceso init se inicia, el nivel de ejecución se inicia en N (none). Luego, entra en el nivel de ejecución S para inicializar el sistema en modo monousuario y, finalmente, pasa a uno de los modos multiusuario. Para averiguar el nivel de ejecución actual, escriba lo siguiente: