systemd exDebian

Introducción
Instalación de systemd
- Instalación de systemd en Debian Wheezy
Configuración de systemd a modo de prueba
Journal el sistema de registro de systemd
- introduccion
- Configuracion basica
Los target
Comandos básicos
Trucos y consejos
Solución de problemas
Fuentes y referencias

Introducción

¿qué es systemd?

systemd es un sistema y un gestor de servicios para Linux, compatible con los init script SysV y LSB, y puede funcionar como un reemplazo para sysvinit.

Dentro de sus características, systemd:
* Proporciona capacidades de paralelización agresivas.
* Utiliza la activación de socket y D-Bus para iniciar los servicios
* Permite el inicio de demonios bajo demanda
* Realiza el seguimiento de procesos utilizando Linux cgroups
* Implementa la lógica de control de servicios basados en la dependencia transaccional
* Realiza un seguimiento de los procesos con el uso de los grupos de control de Linux (cgroups)
* Soporta copia instantánea de volumen (snapshotting) y la restauración de estado del sistema
* Mantiene puntos de montaje y servicios de automontaje implementando un elaborado sistema de gestión de dependencias basado en un control lógico de los servicios

Funcionamiento

systemd inicia y supervisa todo el sistema basándose en la noción de unidades compuestas con un nombre y tipo en coincidencia con un archivo de configuración que lleva el mismo nombre y tipo.

Secuencia de arranque con systemd

Una vez iniciada la pc y llegado al punto donde la BIOS pasa el control al gestor de arranque (grub. lilo , ) éste carga el sistema, kernel y una imagen minima en memoria (initrd) el kernel busca el directorio raiz del sistema ,una vez ubicado y montado el archivo raiz , initrd pasa el control a systemd
systemd carga los controladores , monta el sistema de archivos e inicializa todos los servicios configurados.
systemd activa todas las unidades que tienen como despendencias default.target que tiene vinculos con multi-user.target o graphical-user.target según estén configurados systemd
Se puede ver el arbol de dependencias de default.target con :

$ systemctl  list-dependencies  default.target

Unidades

Systemd provee un sistema de dependencias entre varias entidades llamadas unidades.
Las unidades encapsulan distintos objetos relevantes para el arranque y mantenimiento del sistema.
La mayoría de estas unidades son configuradas en sus propios archivos de configuración. Sin embargo algunos se crean automáticamente a partir de otra configuración, o dinámicamente respondiendo a un estado del sistema, o programándolo durante la ejecución de otra unidad.
Un archivo de configuración de unidad codifica información acerca de cualquiera de las distintas unidades disponibles.
La sintaxis y opciones generales se encuentran en systemd.unit
Opciones adicionales o especificas se encuentran indicadas en las referencias puntuales de cada unidad
Las unidades pueden adquirir diferentes estados
Active Que puede significar iniciada ,con destino, o conectada , dependiendo del tipo de unidad
Inactive que puede significar detenida, sin destino o desconectada , dependiendo del tipo de unidad
También una unidad puede adquirir un estado intermedio entre dos procesos a la espera de ser activada o desactivada , estos estados son llamados ,
Activating y deactivating , respectivamente
Un estado especial llamado failed esta disponible similar a inactive y se produce cuando el servicio ha fallado de algún modo ( el servicio envió un código de error, colapsó, o expiró el tiempo de espera )
Si una unidad entra en este estado se guardara un registro para posterior consulta .
Hay que tener en cuenta que diferentes unidades pueden adquirir distintos sub-estados adicionales a los cinco mencionados mas arriba .
Existen doce tipos diferentes de unidades:

Service: Una unidad .service Controla demonios y los procesos relativos a ellos .
Socket: Codifica información respecto a un IPC network socket(inter-process communication socket), o un FIFO file system socket, controlado y supervisado por systemd, para una activación basada en sockets
cada unidad .socket tiene su unidad .service correspondiente , y establece un canal de comunicación a pedido del cliente.
Target: Las unidades .target codifican información respecto a las unidades target del sistema ,que son utilizadas para agrupar unidades y lograr una buena sincronización entre ellas en el momento del arranque sirven exlusivamente para agrupar unidades via dependencias, establecer y sincronizar nombres que permitan relacionarlas entre si.
Device: Las unidades .device codifican informacion respecto a un dispostitivo incluido en sysfs/udev .
Mount: Las unidades .mount codifican información respecto a un punto de montaje controlado y supervisado por systemd.Permite montar o desmontar un sistema de archivos
Automount: las unidades .automount encapsulan las funcionalidades de automontaje de un sistema de archivos .cada unidad automount figura en una unidad .mount cuando un pedido de acceso ocurre esta unidad monta el sistema de archivos y da acceso .
Snapshot: Las unidades .Snapshot hacen referencia a una instantánea dinámica del estado de ejecución systemd. Son útiles para hacer retroceder a un estado definido después de iniciar/detener temporalmente servicios o similares.
Timer: Las unidades .timer codifican la información acerca de un temporizador, controlado y supervisado por systemd, para la activación basada en temporizador.
Swap: Las unidades .swap codifican la información acerca de un dispositivo móvil o el archivo de paginación de memoria controlada y supervisada por systemd.
Path: Las unidades .path codifican la información sobre la ruta supervisada por systemd, para la activación basada en rutas.
Slice: Las unidades ,silice gestionan los procesos ( Scope y unit), los que pueden ser asignados a un sector específico. Con la posibilidad de configurarse ciertos limites a los recursos que se aplican a todos los procesos de todas las unidades que figuran en ese sector.
Scope: Las unidades .scope gestionan un conjunto de procesos del sistema. A diferencia de las unidades service , las unidades scope gestionan procesos creados externamente, y no hacen una bifurcación de dichos procesos.

Referencias

Instalación de systemd en Debian Wheezy

Antes de explicar como hacer la instalación de systemd en Debian Wheezy debemos aclarar que el mismo fue incluido como una muestra de tecnología. Por lo tanto para su instalación, utilizaremos la versión de systemd del repositorio de wheezy-backports la cual se asemeja a la de testing.

Advertencia: Debido a que a la fecha Debian mantiene a systemd en una etapa de pruebas ya que todabia no ha sido incorporado como reemplazo de sysvinit. Se advierte que la instalación del mismo podría causar problemas de estabilidad del sistema, por lo que su instalación que da bajo la estricta responsabilidad del usuario.

Agregar el repositorio de backports para debian wheezy

# echo deb http://ftp.de.debian.org/debian wheezy-backports main > /etc/apt/sources.list.d/wheezy-backports.list

Nota: Antes de instalar el repositorio verifique de no tiene agregado wheezy-backports en su sources.list
Nota: La ubicación del repositorio es un ejemplo, pero cada uno puede poner el repositorio que este mas serca de su pais o en el que confien más. Para mas información consulte la seccion:

Instalación de systemd

# apt-get update
# apt-get -t wheezy-backports install systemd systemd-sysv

Nota: Al instalar systemd-sysv nos pedirá eliminar sysvinit

Recomendación: Antes de instalar systemd-sysv es aconsejable hacer una copia del archivo /sbin/init en caso que posteriormente se necesite iniciar el sistema con sysvint

# cp -av /sbin/init /sbin/init.sysvinit

Advertencia: Al instalar systemd-sysv se pierde la oportunidad de poder probar systemd sin tener que eliminar sysvinit como se explica en Prueba de systemd sin instalación systemd-sysv

Configuración de systemd a modo de prueba

Es posible probar systemd sin necesidad de instalar el paquete systemd-sysv (quien se encarga de la configuración necesaria para que systemd se inicie de forma persistente), indicando como parámetro de arranque del kernel a:

init=/bin/systemd

Configurar el Inicio con systemd editando GRUB al iniciar el sistema (método temporal)

Estos parámetros pueden introducirse temporalmente durante el inicio del sistema editando el menú de GRUB.

Procedimiento:

Al desplegarse la ventana de opciones de GRUB durante el booteo, se debe presionar la letra "e", esto mostrara una nueva ventana que permite pasar opciones (en forma no persistente) a la configuración de GRUB.

Dicha ventana mostrara (entre otras cosas) una entrada similar a la siguiente :

...
linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root ro quiet
...

En la cual se deberá agregar los parámetros necesarios para que systemd inicie en el arranque del kernel (init=/bin/systemd), quedando de forma similar a:

...
linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root init=/bin/systemd ro quiet
...

Configurar el Inicio con sysvinit editando GRUB al iniciar el sistema (método temporal)

En este caso ya se tendría instalado y configurado el manejador de sistema y gestor de servicios para Linux systemd para que se inicie en forma permanente y se quiere introducir los parámetros para el arranque del kernel con Sysvinit, introduciéndolos temporalmente durante el inicio del sistema al editar el menú de GRUB.

Cabe aclarar que para realizar este procedimiento, previo a la instalación del paquete systemd-sysv se debe realizar la copia de /sbin/init ya que de lo contrario, el mismo no se podría llevar a cabo

# cp -av /sbin/init /sbin/init.sysvinit

Procedimiento:

Dicha ventana mostrara (entre otras cosas) una entrada similar a la siguiente :

...
linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root ro quiet
...

En la cual se deberá agregar los parámetros necesarios para que systemd inicie en el arranque del kernel (init=/sbin/init.sysvinit ), quedando de forma similar a:

...
linux /vmlinuz-3.13-1-686-pae root=/dev/mapper/root-root init=/sbin/init.sysvinit  ro quiet
...

Configurar el Inicio con systemd editando /etc/default/grub (método permanente)

Procedimiento:

1 Desde un emulador de terminal instalar el paquete systemd

# apt-get install systemd

2 Editar el archivo grub que se encuentra en /etc/default

# nano  /etc/default/grub

3 Buscar el texto

….
GRUB_CMDLINE_LINUX_DEFAULT="quiet "
….

4 Agregar el texto

...
GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd"

...

5 Actualizar GRUB

# update-grub2

Journal el sistema de registro de systemd

Introducción

Journal es el sistema de registro de systemd , implementado en la unidad systemd-journald.service.

configuración

El archivo de configuración de systemd-journald.service ,se encuentra en /etc/systemd/journald.conf .
este archivo contiene las distintas opciones para configurar entre otras cosas ,el modo, tipo y tamaño de los log de registro.

Dentro de este archivo, "Storage " configura donde y como se guardaran los datos de registro , opciones como "volatile","persistent","auto", y"none". indican los posibles modos :

storage= volatile : Los datos de journal serán almacenados en memoria de forma volátil en /run/log/journal .
storage=persistent: Los datos serán almacenado preferentemente en el disco en /var/log/journal/ .(que se creara si hace falta)
storage=auto: Esta opción es similar a "persistent" pero el directorio /var/log/journal / no sera creado en forma automática .

Por defecto "storage=auto" por lo tanto para lograr tener un registro persistente de los log es necesario crear el archivo en /var/log/journal/ previamente.

# mkdir -p /var/log/journal

Existen múltiples opciones de configuración

Mas información:

$ man journald.conf

Los target

En systemd los distintos niveles de ejecucion estan asociados y definidos en unas unidades que permiten agrupar los niveles de dependencia de los servicios relacionándolos entre si durante el arranque o bajo demanda .Por ejemplo apagar, iniciar ,reiniciar , Mono-usuario, Multi-usuario ,multiusuario modo gráfico.
Cada unidad iniciara los servicios asociados en ese nivel de ejecucion .
systemd engloba esto en los .target, existen distintos target con un nombre propio y que engloban objetivos similares .(ver
systemd.special)
Estos objetivos implican el inicio de los procesos y servicios necesarios para esa etapa en particular .
Las asociaciones de servicios a sus correspondientes .target se definen en las [Unit] unidades.

Ejemplo de configuracion de una unidad :

[Unit]
Description=Graphical Interface
Requires=multi-user.target
After=multi-user.target
Conflicts=rescue.target
AllowIsolate=yes

[Install]
Alias=default.target

Un target pueden heredar los procesos del anterior y sumarle los propios
Por ejemplo si listamos el árbol de dependencias de default.target

#  systemctl  list-dependencies  default.target

Nos mostrara:

systemctl  list-dependencies  default.target
	default.target
	├─autofs.service
	├─bootlogs.service
	├─cpufrequtils.service
	├─cron.service
	├─decnet.service
	├─display-manager.service─smartmontools.service
	.......................................................................
	...................................................................
	├─systemd-update-utmp-runlevel.service
	├─tor.service
	└─multi-user.target
	  ├─anacron.service
	  ├─atd.service
	  ├─autofs.service
	  ├─avahi-daemon.service
	........................................................
	...................................................................

Como vemos multi-user.target heredo los objetivos de default.target y añadió los suyos
Podemos listar todos los tipos de target disponibles con :

$ systemctl list-units --type=target --all

Que mostrara algo similar a:

UNIT                     LOAD   ACTIVE   SUB    DESCRIPTION
	basic.target             loaded active   active Basic System
	cryptsetup.target        loaded active   active Encrypted Volumes
	emergency.target         loaded inactive dead   Emergency Mode
	final.target             loaded inactive dead   Final Step
	getty.target             loaded active   active Login Prompts
	graphical.target         loaded active   active Graphical Interface
	local-fs-pre.target      loaded active   active Local File Systems (Pre)
	local-fs.target          loaded active   active Local File Systems
	multi-user.target        loaded active   active Multi-User System
	network.target           loaded active   active Network
	..................................................................................
	................................................................................

Tambien podemos ver los target actualmente en uso :

$ systemctl list-units --type=target

Existen target que imitan los runlevels usados en sysvinit .El siguiente listado muestra una relación aproximada con los mismos:

0 runlevel0.target, poweroff.target: Cierra y apaga
1, s, single runlevel1.target, rescue.target: Modo mono usuario
2, 4 runlevel2.target, runlevel4.target, multi-user.target: Similar al 3
3 runlevel3.target, multi-user.target: Multiusuario sin entorno grafico
5 runlevel5.target, graphical.target: Todos los servicios del nivel 3 Mas entorno gráfico
6 runlevel6.target, reboot.target: Reinicio del sistema
emergency emergency.target: Shell de emergencia

Para cambiar el target en uso se utiliza el comando :

# systemctl isolate  multi.user.target

Esto cambia a multiusuario en la actual sesión, en el siguiente reinicio el sistema volverá al target configurado por defecto .
Es posible cambiar el target durante el inicio pasando parámetros al kernel mediante comandos en grub por ejemplo:

systemd.unit=multi-user.target   (equivalente a un runlevel 3)
systemd.unit=rescue.target         (equivalente a un runlevel 1)

Se pueden visualizar las dependencias de cada target con :

systemctl  show -p " wants" graphical.target

Donde " wants" puede ser sustituido por "ReqieredBy",Requires","WantedBy" "Conflists","ConflictedBy","Before","After"

mas información :

Comandos Básicos

Herramientas de análisis y control

Systemd-analyze

Es la herramienta de systemd que permite analizar el proceso de arranque del sistema y medir los tiempos de carga

systemd-analyze

Mostrara en forma sencilla el tiempo empleado durante la carga del sistema ,dividido entre kernel y espacio de usuario.
Ejemplo :

Startup finished in 4.110s (kernel) + 32.181s (userspace) = 36.291s

Podemos obtener un listado mas detallado de todo el proceso en orden decreciente de tiempo empleado

systemd-analyze   blame

Lo que mostrara :

systemd-analyze blame
	13.832s networking.service
	 6.268s kerneloops.service
	 6.102s avahi-daemon.service
	 6.100s systemd-logind.service
	 6.088s exim4.service
	 5.496s systemd-fsck-root.service
	 4.106s autofs.service
	 3.859s rsyslog.service
	 3.749s loadcpufreq.service
	 3.735s tor.service
	 .................
	 ........................

Se puede hacer un análisis mas específico sobre una unidad , obteniendo los tiempos parciales de los procesos previos que demoran su inicio.

systemd-analyze critical-chain  bla.service

Tambien podemos obtener una representacion gráfica de todo el proceso

systemd-analyze  plot >grafico.svg

Crea y guarda un grafico en formato .svg en el directorio de usuario .

systemd-cgls

En los sistemas linux la cantidad de procesos que se ejecutan en forma predeterminada es sustancial.
Saber que proceso hace que cosa y a su vez cuando generan supbrocesos ( procesos hijos ) puede ser complicado .
systemd pone cada proceso generado en un grupo de control cgroup con el nombre del servicio que lo genero .
Los grupo de control en su mas básica expresión simplemente son grupos de procesos que se pueden organizar en una jerarquía y etiquetar individualmente.
Cuando un proceso genera otros procesos, estos procesos hijos se hacen miembro automáticamente del grupo del proceso padre.
Entonces cgroup puede ser utilizado en forma efectiva para etiquetar procesos generados luego que el proceso principal sea lanzado.asegurando de que queden dentro del mismo grupo de control aunque estos procesos hijos generen a su vez subprocesos en forma ramificada Y además es una forma segura de matar el proceso padre y toda la cadena de supbrocesos derivados sin que escape alguno .
systemd provee una herramienta para mostrar los grupos de control en un arbol jerárquico .

$ systemd-cgls

Lo que mostrará ( en el ejemplo en forma acotada ) algo similar a :

systemd-cgls
	├─user
	│ └─1000.user
	│ └─1.session
	│   ├─  726 /bin/login --
	│   ├─ 1153 -bash
	│   ├─ 1303 /bin/sh /usr/bin/startx
	│   ├─ 1320 xinit /home/ale/.xinitrc -- /etc/X11/xinit/xserverrc :0 -auth /tmp/serverauth.qdRjY
	│   ├─ 1321 /usr/bin/X -nolisten tcp :0 -auth /tmp/serverauth.qdRjYJ71z2
	│   ├─ 1327 /usr/bin/fluxbox
	│   ├─ 1338 conky
	...........................................
	........................................
        │ └─22614 /usr/bin/kglobalaccel
	└─system
	├─1 /sbin/init
	├─anacron.service
	│ ├─5836 /usr/sbin/anacron -dsq
	│ ├─9135 /bin/sh -c run-parts --report /etc/cron.daily
	│ ├─9136 run-parts --report /etc/cron.daily
	│ ├─9└─systemd-journald.service
	  └─130 /lib/systemd/systemd-journald
	...skipping...
        ├─ 1338 conky140 /bin/sh /etc/cron.daily/apt
	.............................................................
	..............................................................
	└─1322 /usr/sbin/acpid
	├─cron.service
	│ ├─1120 /usr/sbin/cron
	│ ├─1126 /USR/SBIN/CRON
	│ ├─1131 /bin/sh -c DISPLAY=":0" /home/ale/scripts/noip
	│ ├─1136 /bin/bash /home/ale/scripts/noip
	│ ├─1142 noip2
	│ └─3904 dwb http://www.no-ip.com/hostactive.php?host=bla&domain=myftp.org

	..............................................

Vemos los procesos mostrados mediantes su cgroup, las etiquetas puestas luego del servicio y los subprocesos generados .
De este modo estando cada proceso identificado junto a sus procesos hijos se puede matar el conjunto en su totalidad, por ejemplo:

#  systemctl  kill bla.service

Esto asegura que se envie una señal SIGTERM al conjunto englobado en el cgroup bla.service. ( es posible enviar otras señales,ejemplo:SIGKILL)
La diferencia respecto al modo habitual para detener un servicio

systemctl  stop  bla.service

Es que systemd kill envia directamente una señal a cada miembro del cgroup ;systemcl stop opera mediante el archivo de configuración de cada servicio y depende de que el demonio responda adecuadamente systemd kill resuelve drásticamente el asunto en el caso de no poder hacerlo de este modo.

Mas información en

Systemctl

Es la herramienta principal de systemd que permite verificar y controlar el estado de sus unidades de servicio

$ systemctl

Pasado sin argumentos mostrará un listado de todos los servicios en uso ( activos o no ) y su estado .

$ systemctl list-units

Listará las unidades instaladas.
Las unidades disponibles se encuentran en /lib/systemd/system/ y en /etc/systemd/system/ , las unidades de este ultimo directorio tienen prioridad respecto al anterior.
Se pude obtener un listado de todas las unidades disponibles con :

$ systemctl list-unit-files

Listar por tipo de unidad

$ systemctl  list-units --type=service

Listara todas las unidades .service
O pasandole argumentos especificos:

$ systemctl --failed

Listará las unidades que presentan alguna falla.

Journalctl

Journal permite indicar distintas opciones a la hora de visualizar el contenido, pudiendo ser filtrado por tamaño, antigüedad o por campos mucho más específicos y puntales

Algunos comandos :

journalctl

Mostrara la totalidad del log guardado desde el más antiguo hacia adelante

journalctl -f

Mostrara las ultimas entradas quedando en espera para mostrar las siguientes que se vayan agregando

journalctl -n5

Mostrara 5 lineas

journalctl -f -n

Mostrara n lineas y quedara a la espera de las siguientes entradas

journalctl -b

Mostrara las entradas correspondiente al booteo actual

journalctl -b -p err

Es posible filtrar aun mas los datos mostrando solamente en los campos con errores

journactl --since=yesterday

Mostrara todo el registro desde ayer a partir de 00.00 hs.(o se puede indicar a partir de una hora:minuto ,especificos)

journalctl --since=2014-05-01 --until=2014-05-02

Mostrara el registro entre las fechas acotadas (por defecto desde 00:00 hs, o acotar hora:minuto )

Más información:

$ man journalctl

Manejo de las unidades de servicio

Las unidades de servicio pueden ser iniciadas, detenidas ,reiniciadas, en el momento y/o ,habilitadas al inicio o deshabilitadas al inicio .

# systemctl  start/stop/restart  bla.service

Iniciará/detendrá/reiniciará bla.service

# systemctl status  bla.service

Mostrará el estado de bla.service

systemctl  is-enabled  bla.service

Mostrara si la unidad bla.service esta habilitada o no.

Habilitar o deshabilitar servicios en forma permanente durante el arranque del sistema .

# systemctl enable/disable  bla.service

Habilitará/deshabilitará la carga de bla.service al inicio del sistema .

# systemd  start  bla.service
# systemd  enable bla.service

Iniciará bla.service inmediatamente y lo habilitará para que cargue en el siquiente arranque del sistema en forma permanente .

# systemctl daemon-reload

Reiniciará systemd verificando nuevas configuraciones, unidades o unidades modificadas

Detener, apagar, reiniciar, suspender, hibernar

# systemctl halt

Cerrará y detendrá el sistema

# systemctl poweroff

Cerrará ,detendrá y apagará el sistema

# systemctl reboot

Reiniciará el sistema

# systemctl suspend

Suspender

# systemctl hibernate

Hibernar

Trucos y consejos

Investigar un error con systemctl y journalctl

Las opciones disponibles son amplias ,systemctl puede ser utilizada no solo para controlar el estado de un servicio si no además investigar el origen de un error.
Ejemplo:
Listar las unidades que presentan falla:

$ systemctl --failed

Resultado :

UNIT    LOAD    ACTIVE    SUB    DESCRIPTION
systemd-modules-load.service loaded failed failed Load Kernel Modules

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Comprobamos el estado del servicio que presenta error.

$ systemctl  status systemd-modules-load.service

Resultado:

systemd-modules-load.service - Load Kernel Modules
  Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
  Active: failed (Result: exit-code) since mar 2002-01-01 09:48:10 ART; 12 years 3 months ago
    Docs: man:systemd-modules-load.service(8)
          man:modules-load.d(5)
  Process: 247 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

Obtenemos el numero de proceso (PID) lo que permite investigar un poco mas respecto al error .Ahora utilizamos la herramientas de registro journalctl

journalctl _PID=247

Resultado:

-- Logs begin at mar 2002-01-01 09:48:07 ART, end at vie 2014-05-02 17:20:43 ART. --
ene 01 09:48:10 pcale systemd-modules-load[247]: Failed to insert 'w83627ehf': Device or resource busy

Ahora hemos acotado mas el origen del error , falla al cargar un modulo, asi que :

$ ls -Al /etc/modules-load.d/

Resultado:

total 4
-rw-r--r-- 1 root root 119 feb 25 08:29 cups-filters.conf
lrwxrwxrwx 1 root root  10 abr 27 08:41 modules.conf -> ../modules

$ cat /etc/modules-load.d/modules.conf

Lo que muestra :

# Generated by sensors-detect on Thu Apr  1 19:47:25 2010
# Chip drivers
coretemp
w83627ehf

Tenemos el modulo que causa el error .

Mas información

$ man systemctl

Diagnosticar problemas de arranque

A veces systemd tarda un tiempo muy largo, o parece colgarse en el arranque o en el reinicio/apagado. Como systemd espera un tiempo para iniciar cada servicio antes de tratar de acabar con él, es necesario investigar cual es el servicio que esta causando el problema

El primer método seria quitar "quiet" de la línea de comandos del núcleo (los llamados "cmdline" o "línea de grub")

Procedimiento:
```
# nano /etc/default/grub 
```
Buscar el texto:
```
….
GRUB_CMDLINE_LINUX_DEFAULT="quiet "
….
```
Quitar el texto quiet
```
...
GRUB_CMDLINE_LINUX_DEFAULT=""
...
```
Actualizar GRUB
```
# update-grub2
```
El segundo método consiste en aumentar el nivel de detalle través cmdline: Añadiendo "systemd.log_target = kmsg systemd.log_level = debug" a '/etc/default/grub'
Procedimiento:
```
# nano /etc/default/grub
```
Buscar el texto:
```
….
GRUB_CMDLINE_LINUX_DEFAULT="quiet "
….
```
Agregar el texto
```
...
GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug"
...
```
Tambien se puede agreagar “systemd.sysv_console=1” (0: disabled, 1: enabled) y “log_buf_len=1M”
```
...
GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug systemd.sysv_console=1 log_buf_len=1M"
...
```
Actualizar GRUB
```
# update-grub2
```
El tercer método consiste en Incrementar el nivel de detalle a través del archivo de configuración system.conf
Procedimiento:
```
# nano /etc/systemd/system.conf 
```
Agregar el texto
```
LogLevel=debug
LogTarget=syslog-or-kmsg
SysVConsole=yes 
```

* Nota: la función SysVConsole=yes no hay que introducirla al aplicar dicho método en Debian 10 ya que ha sido retirada del system.conf

Más información:

Journal permitir acceso a un usuario del sistema

Por defecto journal guarda los registros en /var/log/journal/ , el acceso y lectura de dicho directorio es asignado al grupo systemd-journald creado por defecto.
Si se quiere dar acceso a un usuario sin privilegios de root a dichos registros, hay que agregarlo al grupo systemd-journald .
Se crea el directorio de registro :

# mkdir  /var/log/journal

Se agrega el usuario usuario al grupo systemd-journald

# usermod  -a -G  systemd-journald   usuario

Es posible dar acceso a estos registros a usuarios y grupos ver ( )

Journal limitar su tamaño

Si se ha agregado el directorio /var/log/journal haciendo que la información de los log de systemd se mantengan en forma permanente, puede que sea conveniente determinar el tamaño máximo en MB de dichos archivos para que no terminen ocupando un espacio desproporcionado en la partición /var editando el archivo /etc/systemd/journald.conf y estableciendo un límite de 50 o 100 MB. Cabe aclarar que estos valores son meramente ejemplificativos.

# nano '/etc/systemd/journald.conf'

y agregar el texto

SystemMaxUse=100M

Scripts al inicio

Para conseguir que un script sea cargado al inicio ( o en alguna otra instancia ) se debe crear una unidad de servicio .service
Un archivo de texto con las configuraciones y directivas en /etc/systemd/system/.
Por ejemplo :

# nano /etc/systemd/system/miservicio.service

El contenido básico de dicho archivo puede ser similar a :

[Unit]
Description=Mi script

[Service]
ExecStart=/ruta/completa/miscript

[Install]
WantedBy=multi-user.target

Esta configuración es un ejemplo, cada sección en este archivo [Unit] ; [Service] ; [Install], tienen multiples opciones según el comportamiento requerido para la unidad y el servicio
De este modo y en el ejemplo se asume que el servicio sera habilitado en el target multi-user .
Si lo que se quiere lanzar al inicio es un shell script ,como miscript es necesario que el encabezado del mismo incluya el shebang , ejemplo:

#!/bin/bash 
...................
..................

Arrancar Debian con Num Lock activada en las TTYs

Creamos el servicio numlock.service:

# editor /etc/systemd/system/numlock.service

Su contenido es:

[Unit]
Description=Activar el teclado numérico en las TTYs

[Service]
ExecStart=/bin/bash -c 'for tty in /dev/tty{1..6}; do /usr/bin/setleds -D +num < \"$tty\"; done'

[Install]
WantedBy=multi-user.target

Lo configuramos en el arranque:

systemctl enable numlock.service

Más información:

systemd

Solapas principales

Introducción

¿qué es systemd?

Funcionamiento

Secuencia de arranque con systemd

Unidades

Referencias

Instalación de systemd en Debian Wheezy

Configuración de systemd a modo de prueba

Configurar el Inicio con systemd editando GRUB al iniciar el sistema (método temporal)

Configurar el Inicio con sysvinit editando GRUB al iniciar el sistema (método temporal)

Configurar el Inicio con systemd editando /etc/default/grub (método permanente)

Journal el sistema de registro de systemd

Introducción

configuración

Mas información:

Los target

Comandos Básicos

Herramientas de análisis y control

Systemd-analyze

systemd-cgls

Systemctl

Journalctl

Manejo de las unidades de servicio

Habilitar o deshabilitar servicios en forma permanente durante el arranque del sistema .

Detener, apagar, reiniciar, suspender, hibernar

Trucos y consejos

Investigar un error con systemctl y journalctl

Mas información

Diagnosticar problemas de arranque

Journal permitir acceso a un usuario del sistema

Journal limitar su tamaño

Scripts al inicio

Arrancar Debian con Num Lock activada en las TTYs

Fuentes y referencias