Curso: Gestión de Servicios y Planificación de Tareas en Linux

Objetivos de Aprendizaje

Al final de este curso, usted será capaz de:

Comprender la diferencia entre demonios y servicios
Dominar systemd y systemctl
Crear y gestionar sus propios servicios systemd
Planificar tareas con cron y at
Realizar copias de seguridad con rsync
Gestionar la rotación de logs con logrotate

Parte 1 – Introducción a Demonios y Servicios

1.1 Definición: ¿Qué es un demonio?

Un demonio (o daemon en inglés) es un programa que se ejecuta en segundo plano, sin interfaz gráfica, y que trabaja silenciosamente para ofrecer servicios esenciales al sistema o a los usuarios.

Ejemplos simples:

sshd: permite conexiones remotas vía SSH
httpd: servidor web Apache
crond: planifica la ejecución de tareas
systemd: orquesta todos los demás servicios al arrancar

1.2 Definición Técnica: Naturaleza y Función de un Demonio

Un demonio es un proceso de sistema independiente, lanzado:

ya sea al arrancar el sistema
o manualmente por el administrador
y que no se detiene hasta que es explícitamente parado.

Es:

separado de cualquier terminal o sesión de usuario (tty)
a menudo creado por el proceso init (PID 1), actualmente systemd en la mayoría de las distribuciones modernas.

1.3 ¿Cómo se crean los demonios?

3 pasos:

Lanzamiento inicial mediante un archivo de configuración o script
Desvinculación del terminal actual
Ejecución continua, a menudo en un bucle infinito, hasta ser detenido o fallar

En los sistemas modernos, systemd se encarga de esta gestión automáticamente a través de unidades .service.

1.4 Los nombres de los demonios terminan en `d`

Es una convención de nomenclatura:

sshd → Secure Shell Daemon
ftpd → FTP Daemon
systemd → System Daemon
rsyslogd → Remote SYSLOG Daemon

1.5 Lista de demonios comunes en Linux

Demonio	Función principal
`sshd`	Permite conexiones SSH
`crond`	Gestiona tareas programadas
`httpd`	Proporciona un servicio web (Apache)
`systemd`	Controla los servicios y el arranque del sistema
`rsyslogd`	Gestiona la registración del sistema
`cupsd`	Gestiona la impresión
`ntpd`	Sincroniza la hora con servidores NTP

1.6 Demonios vs Servicios

Un demonio es un proceso, un servicio es una abstracción lógica.
Un servicio puede ser un demonio, pero no siempre (ej: tmp.mount no es un proceso sino una unidad).

Elemento	Demonio	Servicio
Naturaleza	Proceso en segundo plano	Unidad gestionada por systemd
¿Visible?	No, salvo vía `ps`, `systemctl`	Visible con `systemctl`
Ejemplo	`sshd`	`sshd.service`

Un servicio es simplemente systemd

Criterio	Demonio	Servicio (systemd)
Definición	Programa que corre en segundo plano	Unidad gestionada por `systemd` para lanzar y gestionar un programa
Lanzamiento	Automático o manual (a menudo al arrancar)	Gestionado con `systemctl` (`start`, `stop`, `enable`, etc.)
¿Corre en segundo plano?	Sí	No siempre (ej: un script corto puede ser un servicio)
¿Gestionado por `systemctl`?	No, salvo si está integrado como servicio	Sí
¿Requiere archivo `.service`?	No	Sí (ej: `/etc/systemd/system/mi_servicio.service`)
¿Puede existir sin `systemd`?	Sí (sistemas antiguos, scripts manuales)	No (servicio = unidad systemd)
Ejemplos	`sshd`, `cron`, script infinito en segundo plano	`nginx.service`, `docker.service`, `mi_script.service`

A recordar:

Un demonio es un programa.
Un servicio es una forma de gestionar ese programa con systemd.

1.7 Control de los demonios

En systemd, todos los demonios se controlan mediante systemctl, con los siguientes comandos:

Acción	Comando
Iniciar	`sudo systemctl start sshd`
Detener	`sudo systemctl stop sshd`
Reiniciar	`sudo systemctl restart sshd`
Ver estado	`sudo systemctl status sshd`
Activar al arranque	`sudo systemctl enable sshd`
Desactivar al arranque	`sudo systemctl disable sshd`

1.8 En Resumen – Puntos Clave a Recordar

Un demonio es un proceso sin interfaz, que proporciona un servicio.
Suele iniciarse al arranque, gestionado por systemd.
Para ver, activar, desactivar o reiniciar un demonio, se usa systemctl.
Todos los servicios de sistema modernos son ahora unidades gestionadas por systemd.

Parte 2 – Introducción a systemd y systemctl

2.1 ¿Qué es systemd?

systemd es el sistema de inicialización por defecto de la mayoría de las distribuciones Linux modernas (Ubuntu, Fedora, Debian, CentOS, etc.). Reemplaza al antiguo sistema SysVinit y sirve para:

Inicializar el sistema al arranque (montaje de discos, inicio de servicios, etc.)
Gestionar todos los servicios del sistema de manera centralizada
Ofrecer herramientas integradas como systemctl, journalctl, systemd-analyze, systemd-nspawn, etc.

Ventajas de systemd:

Arranque más rápido gracias a una inicialización paralela
Reinicio automático de servicios en caso de fallo
Gestión avanzada de dependencias entre servicios
Centralización de la registración

2.2 El rol de `systemctl`

systemctl es la herramienta principal en línea de comandos para interactuar con systemd.

Permite:

Iniciar, detener o reiniciar un servicio
Activar o desactivar un servicio al arranque
Obtener el estado de un servicio
Mostrar todos los servicios activos o inactivos

2.3 Comandos fundamentales con `systemctl`

Acción	Comando
Iniciar un servicio	`sudo systemctl start nombre_del_servicio`
Detener un servicio	`sudo systemctl stop nombre_del_servicio`
Reiniciar un servicio	`sudo systemctl restart nombre_del_servicio`
Recargar la configuración	`sudo systemctl reload nombre_del_servicio`
Verificar el estado	`systemctl status nombre_del_servicio`
Activar un servicio al arranque	`sudo systemctl enable nombre_del_servicio`
Desactivar un servicio al arranque	`sudo systemctl disable nombre_del_servicio`

Reemplace nombre_del_servicio por el nombre real del servicio correspondiente (ej: sshd, nginx, apache2, etc.).

2.4 Visualización de los servicios

Mostrar todos los servicios activos:

systemctl list-units --type=service --state=running

Mostrar todos los servicios (activos o no):

systemctl list-units --type=service

2.5 Uso de `journalctl` para consultar los logs

systemd integra un sistema de logs centralizado: journald. Puede consultar los registros con el comando journalctl.

Objetivo	Comando
Ver todos los logs	`journalctl`
Ver los logs de un servicio específico	`journalctl -u nombre_del_servicio`
Ver los logs desde el último arranque	`journalctl -b`
Seguir los logs en tiempo real	`journalctl -f`
Ver los logs de la última hora	`journalctl --since "1 hour ago"`

2.6 Las unidades (`units`) en systemd

Una unidad es un objeto que systemd puede gestionar. Cada unidad corresponde a un archivo con una extensión específica.

Tipo de unidad	Extensión	Ejemplo
Servicio	`.service`	`nginx.service`
Montaje	`.mount`	`home.mount`
Socket	`.socket`	`cups.socket`
Objetivo	`.target`	`multi-user.target`
Temporizador	`.timer`	`logrotate.timer`

2.7 Los objetivos (`targets`) de systemd

Un objetivo representa un estado global del sistema, equivalente a los antiguos niveles de ejecución (runlevels).

Nombre del objetivo	Descripción
`rescue.target`	Modo de recuperación (acceso root únicamente)
`multi-user.target`	Modo multiusuario sin interfaz gráfica
`graphical.target`	Modo con interfaz gráfica
`default.target`	Objetivo por defecto al arrancar

Cambiar el objetivo actual:

sudo systemctl isolate multi-user.target

2.8 Análisis del rendimiento de arranque

Medir el tiempo total de arranque:

systemd-analyze

Listar los servicios ordenados por tiempo de carga:

systemd-analyze blame

Ver la cadena de dependencias críticas:

systemd-analyze critical-chain

2.9 Gestionar los reinicios automáticos

Para forzar el reinicio automático de un servicio tras un fallo, modifique o cree una unidad .service con:

[Service]
ExecStart=/ruta/al/script
Restart=always
RestartSec=5

Esto reinicia el servicio 5 segundos después de cada fallo.

2.10 Resumen

systemd es el gestor de unidades moderno de los sistemas Linux
systemctl es la interfaz de línea de comandos para interactuar con systemd
Los servicios, objetivos, sockets y otros recursos se llaman unidades
journalctl permite consultar los logs del sistema
Herramientas como systemd-analyze permiten analizar el rendimiento al arranque

Parte 3 – Crear y Gestionar sus Propios Servicios con systemd

3.1 Objetivo de esta parte

Comprender cómo:

Crear una unidad de servicio personalizada
Integrar un script de sistema en systemd
Probar, activar, desactivar y reiniciar este servicio

3.2 Estructura de un archivo `.service`

Los archivos de servicio se encuentran generalmente en:

/etc/systemd/system/ (unidades personalizadas y persistentes)
/lib/systemd/system/ (unidades instaladas por los paquetes)

Ejemplo de archivo `webapp.service`:

[Unit]
Description=Servicio personalizado para lanzar una aplicación web
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Explicación de las secciones:

[Unit]: dependencias del servicio, descripción
[Service]: comando a ejecutar, política de reinicio
[Install]: objetivo de activación (aquí, nivel multiusuario)

3.3 Pasos para crear un servicio systemd personalizado

Paso 1 – Escribir o localizar el script a ejecutar

Ejemplo:

sudo nano /usr/local/bin/webapp

Contenido del script:

#!/bin/bash
while true; do
  echo "Aplicación en ejecución" >> /var/log/webapp.log
  sleep 30
done

Hacer el script ejecutable:

sudo chmod +x /usr/local/bin/webapp

Paso 2 – Crear la unidad de servicio

sudo nano /etc/systemd/system/webapp.service

Copie el siguiente contenido:

[Unit]
Description=Web Application Custom Service
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Paso 3 – Activar e iniciar el servicio

Recargar systemd para tener en cuenta el nuevo archivo:

sudo systemctl daemon-reload

Activar el servicio al arranque:

sudo systemctl enable webapp

Iniciar el servicio:

sudo systemctl start webapp

Paso 4 – Verificar el correcto funcionamiento

Mostrar el estado del servicio:

systemctl status webapp

Verificar los logs:

journalctl -u webapp

3.4 Modificar un servicio ya existente

Si modifica el archivo .service:

Guarde los cambios
Recargue la configuración:

sudo systemctl daemon-reload

Reinicie el servicio:

sudo systemctl restart webapp

3.5 Eliminar un servicio personalizado

Desactivar el servicio:

sudo systemctl disable webapp

Detener el servicio:

sudo systemctl stop webapp

Eliminar el archivo de unidad:

sudo rm /etc/systemd/system/webapp.service

Recargar systemd:

sudo systemctl daemon-reload

3.6 Caso práctico: Reinicio automático de un script que falla

En el bloque [Service], utilice:

Restart=always
RestartSec=5

Esto permite:

Un reinicio automático tras un fallo
Una espera de 5 segundos entre cada reinicio

3.7 Caso práctico: Servicio temporal no persistente

Crear un servicio que se desea ejecutar solo una vez, sin registrarlo para futuros arranques:

sudo systemctl start /etc/systemd/system/webapp.service

Sin enable, el servicio no se lanzará en el próximo arranque.

3.8 Resumen

Los servicios personalizados systemd se definen en archivos .service
Permiten integrar cualquier script al sistema
El uso de los comandos daemon-reload, enable, start, status es esencial
Un buen servicio incluye una política de reinicio robusta
La estructura [Unit], [Service], [Install] es obligatoria

Anexo de parte 3 – No se puede "matar" un servicio con kill o lsof

Este anexo demuestra que no se puede detener de forma permanente un servicio gestionado por systemd usando kill, kill -9 o atacando el proceso (ej. vía lsof / ss). systemd lo reinicia mientras la política Restart=always esté activa. La única forma correcta de detenerlo es systemctl stop (y eventualmente disable o mask).

Verificar que el servicio está funcionando y escribiendo en el log

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l

Ver el PID del servicio

sudo systemctl status webapp

Verá una línea como: Main PID: 1234 (webapp).

Matar el proceso con kill (SIGTERM)

sudo kill 1234

Luego volver a verificar:

sudo systemctl status webapp

Observará que el servicio vuelve a estar active (running) con un nuevo PID: systemd lo ha reiniciado.

Más agresivo: kill -9 (SIGKILL)

sudo kill -9 <NUEVO_PID>
sudo systemctl status webapp

Mismo resultado: systemd reinicia de nuevo el proceso, porque Restart=always.

Prueba en directo

En una terminal, siga los logs del servicio:

sudo journalctl -u webapp -f

Verá los reinicios sucesivos tras cada kill o kill -9.

La solución: detener vía systemd

sudo systemctl stop webapp
sudo systemctl status webapp

Para evitar que el servicio se reinicie en el próximo arranque o sea relanzado por systemd:

Opción A (simple) – Desactivar al arranque

sudo systemctl disable webapp

Opción B (fuerte) – Enmascarar el servicio (imposible de iniciar)

sudo systemctl mask webapp

Después de mask, incluso systemctl start webapp no podrá iniciarlo hasta que ejecute sudo systemctl unmask webapp.

Recordatorio: señales y herramientas

Acción	Comando / herramienta
Terminación "limpia" (SIGTERM)	`kill -15 <PID>` o `kill <PID>`
Forzar la detención (SIGKILL)	`kill -9 <PID>`
Ver quién usa puertos / archivos	`sudo lsof -i`, `sudo lsof -i :80`
Ver puertos TCP/UDP en escucha	`sudo ss -ltnp`, `sudo ss -lunp`, `sudo ss -ltnp \| grep -i ...`

Estas herramientas sirven para diagnosticar (qué proceso escucha en un puerto, etc.); para detener un servicio, debe usar systemctl stop.

Anexo de parte 3 (2) – Mismo ejercicio con el servicio webapp (escenario tipo examen)

Este anexo retoma la misma demostración que en el Anexo 1, pero usando únicamente el servicio webapp creado en el paso 3 de este capítulo (script que escribe en /var/log/webapp.log), sin nginx ni Wiki.js. Puede servir de base para un examen del tipo Servicios systemd y gestión de procesos.

Requisitos previos: el servicio webapp ha sido creado, activado e iniciado como en las secciones 3.2 y 3.3 (script /usr/local/bin/webapp, unidad /etc/systemd/system/webapp.service, Restart=always).

Paso 1 – Verificación del servicio y del log

Verificar que el servicio está funcionando y escribiendo en el log:

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l
sudo systemctl status webapp

En la salida de systemctl status webapp, anotar la línea Main PID: XXXX (webapp).

Paso 2 – Intento de detención manual (kill)

Reemplace <PID> por el Main PID mostrado:

sudo kill -15 <PID>
# o simplemente: sudo kill <PID>

Luego volver a verificar:

sudo systemctl status webapp

Observación: el servicio vuelve a estar active (running) con un nuevo PID; systemd lo ha reiniciado debido a Restart=always.

Paso 3 – Intento más agresivo (kill -9)

Utilice el nuevo PID mostrado por systemctl status webapp:

sudo kill -9 <NUEVO_PID>
sudo systemctl status webapp

Observación: mismo resultado — systemd reinicia de nuevo el proceso.

Paso 4 – Prueba en directo (journalctl)

En una terminal, siga los logs del servicio para ver los reinicios tras cada kill:

sudo journalctl -u webapp -f

Paso 5 – Identificación del servicio (si partimos del proceso)

Si solo tuviéramos un PID o un puerto, podríamos identificar el servicio así:

systemctl list-units --type=service --state=running | grep -i webapp
ps aux | grep webapp
ls -l /etc/systemd/system/ | grep webapp

Para un servicio escuchando en un puerto (ej. 3000), también usaríamos:

sudo lsof -i -P -n | grep 3000
sudo ss -ltnp | grep 3000

Aquí, webapp no escucha en ningún puerto; solo llena /var/log/webapp.log.

Paso 6 – Solución: detención y desactivación vía systemd

Detención inmediata:

sudo systemctl stop webapp
sudo systemctl status webapp

Desactivación al arranque (el servicio no se reiniciará en el próximo boot):

sudo systemctl disable webapp

Opción más fuerte — enmascarar el servicio (imposible de iniciar mientras esté enmascarado):

sudo systemctl mask webapp

Para deshacer el enmascaramiento más tarde: sudo systemctl unmask webapp.

Herramientas complementarias (bonus) – Investigación y diagnóstico

Estos comandos permiten profundizar la investigación sobre los servicios y los puertos. Son útiles en exámenes o para solucionar problemas.

1. `systemd-cgls` — Árbol de grupos de control (cgroups)

Muestra la jerarquía de cgroups gestionados por systemd: cada servicio (incluido webapp) vive en un subárbol. Útil para ver cómo systemd agrupa los procesos.

systemd-cgls

Para ver solo la parte referente a nuestro servicio:

systemd-cgls | grep -A 5 webapp

¿Para qué sirve? Entender que systemd aísla y sigue cada unidad en un cgroup; esto explica por qué un simple kill del proceso no "desinscribe" el servicio — systemd vigila la unidad y la reinicia según Restart=always.

2. `ss -lptn` — Puertos TCP en escucha y procesos

Lista los sockets TCP en escucha con el PID y el programa asociado (-l escucha, -p procesos, -t TCP, -n puertos en numérico).

sudo ss -lptn

Ejemplo de salida (extracto):

LISTEN  0  128  *:80    *:*  users:(("nginx",pid=1234,fd=6))
LISTEN  0  128  *:3000  *:*  users:(("node",pid=5678,fd=21))

En nuestro contexto: el servicio webapp del paso 3 no escucha en ningún puerto (solo escribe en /var/log/webapp.log). Si más adelante crea un servicio que escuche en el puerto 3000 (por ejemplo, una API o un proxy), lo verá aquí. Es el equivalente moderno de netstat -lptn, más rápido.

3. `fuser -k 3000/tcp` — Matar procesos que usan un puerto

fuser indica qué procesos usan un archivo o un puerto. La opción -k envía SIGKILL a esos procesos.

Ejemplo para el puerto 3000 (a usar si un servicio escucha en ese puerto):

sudo fuser -k 3000/tcp

Comportamiento pedagógico: si un servicio systemd (por ejemplo, un futuro "webapp-api") escuchara en el puerto 3000 con Restart=always, tras fuser -k 3000/tcp el proceso sería matado, pero systemd lo reiniciaría y el puerto volvería a estar ocupado. Para liberar el puerto de forma permanente, hay que usar systemctl stop <servicio> (y eventualmente disable).

Sin -k, solo muestra los PID sin matar: sudo fuser -v 3000/tcp.

4. `journalctl -u webapp` — Logs del servicio (equivalente a `journalctl -u wikijs.service`)

Muestra todos los mensajes journald para la unidad webapp (inicios, paradas, reinicios, errores).

journalctl -u webapp

Variantes útiles:

Comando	Efecto
`journalctl -u webapp`	Todos los logs del servicio
`journalctl -u webapp -f`	Seguir los logs en tiempo real (como `tail -f`)
`journalctl -u webapp -n 50`	Las últimas 50 líneas
`journalctl -u webapp --since "1 hour ago"`	Logs de la última hora

¿Para qué sirve? Ver la prueba de que systemd reinicia el servicio tras un kill o un fuser -k, y diagnosticar errores al inicio.

Síntesis (tipo examen)

Acción	Comando	¿Eficaz?
Detener el proceso con una señal	`kill -15 <PID>` o `kill -9 <PID>`	No — systemd reinicia el servicio
Detener el servicio correctamente	`sudo systemctl stop webapp`	Sí
Evitar el reinicio al arranque	`sudo systemctl disable webapp`	Sí
Impedir cualquier inicio (incluso manual)	`sudo systemctl mask webapp`	Sí

A recordar: con un servicio systemd configurado en Restart=always, kill y kill -9 no son suficientes; hay que usar systemctl stop, luego disable (y eventualmente mask) para una desactivación definitiva.

Parte 4 – Planificación de Tareas con cron

4.1 Introducción

cron es una herramienta que permite programar tareas repetitivas en Linux. El demonio crond se ejecuta en segundo plano y lee los archivos crontab para ejecutar los comandos en una fecha/hora precisa.

4.2 Estructura de una tarea cron

*     *     *     *     *   comando a ejecutar
-     -     -     -     -
|     |     |     |     |
|     |     |     |     +----- día de la semana (0 a 6, domingo = 0)
|     |     |     +----------- mes (1 a 12)
|     |     +----------------- día del mes (1 a 31)
|     +----------------------- hora (0 a 23)
+---------------------------- minuto (0 a 59)

4.3 Truco para practicar rápidamente

Modificar la crontab para el usuario actual:

crontab -e

Mostrar las tareas cron existentes:

crontab -l

4.4 Ejercicio 1 – Copia de seguridad de /etc todos los domingos a las 3h

Objetivo:

Crear un script que archive /etc en /var/backups.

Pasos:

Crear una carpeta de ejercicios:

mkdir ~/cron_tp && cd ~/cron_tp

Crear un archivo backup.sh:

nano backup.sh

Contenido:

#!/bin/bash
tar -czf /var/backups/etc-backup-$(date +%Y%m%d).tar.gz /etc

Hacer el script ejecutable:

chmod +x backup.sh

Crear la carpeta de destino si es necesario:

sudo mkdir -p /var/backups

Añadir a la crontab:

crontab -e

Añadir la siguiente línea:

0 3 * * 0 /home/usuario/cron_tp/backup.sh

Reemplace usuario por su nombre de usuario Linux.

4.5 Ejercicio 2 – Diviértase con texto

Objetivo:

Escribir "¡Hola! Estamos a [fecha]" cada 5 minutos en un archivo.

Comando en la crontab:

*/5 * * * * echo "¡Hola! Estamos a $(date)" >> /tmp/hola.txt

Luego verifique:

tail /tmp/hola.txt

4.6 Ejercicio 3 – Crear una página web dinámica que cambie cada minuto

Objetivo:

Descargar diferentes páginas web cada minuto y mostrarlas en la carpeta web.

Pasos:

Crear un archivo mypage.sh:

nano ~/cron_tp/mypage.sh

Contenido:

#!/bin/bash
urls=("www.yahoo.com" "www.cmaisonneuve.qc.ca" "www.crosemont.qc.ca" "www.netflix.com")

index_file="/home/$USER/index.txt"
backup_dir="/var/www/html"

index=0
if [[ -f "$index_file" ]]; then
  read -r index < "$index_file"
fi

url=${urls[$((index % ${#urls[@]}))]}
wget -qO "$backup_dir/index.html" --timeout=10 "$url"

next_index=$(( (index + 1) % ${#urls[@]} ))
echo "$next_index" > "$index_file"

Hacer el script ejecutable:

chmod +x ~/cron_tp/mypage.sh

Lanzar la tarea cada minuto:

crontab -e

Añadir:

* * * * * /home/usuario/cron_tp/mypage.sh

Probar accediendo a:

http://localhost/index.html

Cada minuto, la página cambiará automáticamente.

4.7 Ejercicio 4 – Observar los procesos y los usuarios

Objetivo:

Observar quién está conectado y qué procesos están en ejecución entre las 9h y las 17h.

Añadir a la crontab:

# Cada hora entre 9h y 17h: procesos
0 9-17 * * 1-5 ps aux >> /var/log/procesos.txt

# Cada 5 minutos entre 9h y 17h: usuarios conectados
*/5 9-17 * * 1-5 who >> /var/log/quien.txt

Luego visualizar:

tail /var/log/procesos.txt
tail /var/log/quien.txt

4.8 Truco: probar sus tareas cron en directo

Para asegurarse de que todo funciona:

Poner una tarea cada minuto:

* * * * * echo "Tarea de prueba a $(date)" >> ~/cron.log

Lanzar:

tail -f ~/cron.log

Espere un minuto: la línea aparecerá automáticamente.

4.9 Resumen

cron permite ejecutar scripts en momentos precisos, automáticamente.
Un script cron debe ser ejecutable y especificar una ruta absoluta.
Puede observar los resultados con tail, o crear archivos .log para verificar sus pruebas.
Este sistema permite hacer copias de seguridad, pruebas automatizadas o actualizar dinámicamente servicios.

Parte 5 – Tareas Puntuales con `at`

5.1 ¿Qué es `at`?

El programa at permite programar una tarea única para ejecutarse más tarde, una sola vez (a diferencia de cron, que es repetitivo).

Es perfecto para:

Planificar un reinicio del sistema
Lanzar un script de procesamiento diferido
Automatizar una operación sensible en un momento preciso

5.2 Verificación e instalación del servicio `atd`

Antes de nada, asegúrese de que el demonio atd está activo:

sudo systemctl start atd
sudo systemctl enable atd
sudo systemctl status atd

Si at no está instalado:

sudo apt install at   # Debian/Ubuntu
sudo yum install at   # CentOS/RHEL

5.3 Sintaxis básica

at <hora o momento>

Ejemplos:

at now + 1 minute
at 17:00
at 09:30 tomorrow
at now + 2 days

Una vez en el editor at>, escriba el comando a ejecutar, luego termine con Ctrl + D.

5.4 Ejercicio 1 – Planificar un mensaje diferido

Objetivo:

Mostrar un mensaje en su terminal en 1 minuto.

Ejecute el comando:

at now + 1 minute

En el prompt at>, escriba:

echo "Este es un mensaje planificado con at"

Termine con:

Ctrl + D

Espere un minuto y verifique que el mensaje aparece.

5.5 Ejercicio 2 – Script diferido en otra terminal

Objetivo:

Mostrar un mensaje en otra terminal (ej: /dev/pts/0).

Cree un script tratamiento.sh:

nano ~/cron_tp/tratamiento.sh

Contenido:

#!/bin/bash
echo "Mensaje diferido en el terminal /dev/pts/0" > /dev/pts/0

Hacer el script ejecutable:

chmod +x ~/cron_tp/tratamiento.sh

Planificar el script:

at now + 2 minutes -f ~/cron_tp/tratamiento.sh

Abra la terminal pts/0 en paralelo y observe.

5.6 Gestión de tareas `at`

Acción	Comando
Ver las tareas planificadas	`atq` o `at -l`
Eliminar una tarea (ID = 5 por ej.)	`atrm 5` o `at -d 5`
Ver el contenido de la tarea ID 5	`at -c 5`

5.7 Control de acceso a `at`

Archivo	Función
`/etc/at.allow`	Solo los usuarios listados aquí pueden usar `at`
`/etc/at.deny`	Todos los usuarios excepto los listados aquí pueden usar `at`

Prioridad:

Si existe at.allow, solo los usuarios en este archivo tienen derecho.
Si no, se aplica at.deny.

Ejemplo: prohibir a `toto`

echo toto >> /etc/at.deny

5.8 Ejercicio 3 – Planificar un reinicio el viernes a las 17h

Objetivo:

Automatizar un reinicio en una fecha precisa.

Escriba:

at 17:00 Fri

En el prompt at>, escriba:

sudo /sbin/shutdown -r now

Termine con Ctrl + D

Nota: Para probar sin reiniciar, utilice echo "Reinicio previsto" en su lugar.

5.9 Ejercicio 4 – Script automático en 2 días

Cree un script simple:

echo "echo Tratamiento terminado en 2 días" > ~/cron_tp/futuro.sh
chmod +x ~/cron_tp/futuro.sh

Planifíquelo:

at now + 2 days -f ~/cron_tp/futuro.sh

5.10 Resumen

at es útil para tareas puntuales, únicas, diferidas.
Es complementario de cron, que es cíclico.
Puede observar inmediatamente el efecto con echo, o construir scripts diferidos.

Parte 6 – Copias de Seguridad Avanzadas y Planificadas con `rsync`

6.1 ¿Por qué usar `rsync`?

rsync es una herramienta de sincronización potente que permite copiar archivos:

localmente o entre dos máquinas
de manera optimizada (solo copia los archivos modificados)
con compresión, filtrado, copia de seguridad y registro

Es ideal para:

copias de seguridad regulares
migraciones de servidores
copias diferenciales rápidas

6.2 Sintaxis básica

rsync [opciones] origen destino

Ejemplo simple:

rsync -av /home/user/documents /mnt/backup/

Opciones frecuentes:

-a: archive (preserva permisos, enlaces, fechas)
-v: verbose (muestra lo que se copia)
--delete: elimina archivos ausentes en el origen
--bwlimit=KBps: limita el ancho de banda usado

6.3 Ejercicio 1 – Copia de seguridad local con limitación de ancho de banda

Objetivo:

Respaldar la carpeta /home en /mnt/backup todas las noches a las 20h, sin saturar el ancho de banda.

Pasos:

Crear el script:

mkdir -p ~/cron_tp
nano ~/cron_tp/sync_home.sh

Contenido:

#!/bin/bash
rsync -av --delete --bwlimit=200 /home/ /mnt/backup/

Hacer el script ejecutable:

chmod +x ~/cron_tp/sync_home.sh

Añadir en crontab:

crontab -e

Añadir:

0 20 * * * /home/usuario/cron_tp/sync_home.sh

(Reemplace usuario por su nombre real)

6.4 Ejercicio 2 – Sincronización remota

Objetivo:

Sincronizar /var/www hacia otro servidor vía SSH.

Comando directo (probar manualmente antes de automatizar):

rsync -avz -e ssh /var/www user@remote_host:/backup/www

Script automatizado:

nano ~/cron_tp/rsync_remote.sh

Contenido:

#!/bin/bash
rsync -az -e ssh /var/www user@192.168.0.100:/backup/www

Crontab (ejecución diaria a la 01h):

0 1 * * * /home/usuario/cron_tp/rsync_remote.sh

Pre-requisitos:

acceso SSH sin contraseña (clave pública/privada configurada)
permisos de escritura en /backup/www en la máquina remota

6.5 Ejercicio 3 – Copia de seguridad solo por la noche

Objetivo:

Limitar la ejecución de rsync a horas no laborables (19h a 7h). Detener cualquier proceso rsync durante el día.

Pasos:

Script de inicio de rsync:

crontab -e

Añadir:

0 19 * * * /home/usuario/cron_tp/sync_home.sh

Script de parada de seguridad:

0 7 * * * pkill rsync

Esto garantiza que:

rsync comienza a las 19h
Si sigue activo a las 7h, se mata

6.6 Ejercicio 4 – Copia de seguridad con registro

Script:

nano ~/cron_tp/rsync_logged.sh

Contenido:

#!/bin/bash
date >> /var/log/rsync_backup.log
rsync -av --delete /home /mnt/backup >> /var/log/rsync_backup.log 2>&1

Planificación diaria:

0 22 * * * /home/usuario/cron_tp/rsync_logged.sh

Lectura del registro:

tail -n 20 /var/log/rsync_backup.log

6.7 Resumen

rsync es una herramienta rápida, inteligente y controlable
Puede ser limitado en ancho de banda con --bwlimit
Puede ser automatizado con cron
Puede ser restringido a ciertos horarios
Permite un registro completo para auditoría y seguimiento

Parte 7 – Gestión de Logs y Rotación con `logrotate`

7.1 ¿Por qué usar `logrotate`?

Los registros del sistema (en /var/log/) aumentan continuamente con el tiempo:

Pueden llenar el disco
Se vuelven difíciles de consultar
Pueden reducir el rendimiento si no se gestionan bien

logrotate permite:

Hacer una rotación automática de logs
Eliminar o comprimir los archivos antiguos
Conservar un historial limitado en el tiempo
Ejecutar un comando tras la rotación (ej: reiniciar un servicio)

7.2 Funcionamiento general

logrotate generalmente se ejecuta diariamente por cron, vía:

/etc/cron.daily/logrotate

Lee la configuración global:

/etc/logrotate.conf

Y las configuraciones específicas:

/etc/logrotate.d/

7.3 Sintaxis de un archivo de configuración

Ejemplo:

/var/log/webapp.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

Explicaciones:

weekly: rotación cada semana
rotate 4: conservar 4 archivos antiguos
compress: comprimir los logs antiguos
missingok: no mostrar error si el archivo falta
notifempty: no rotar el archivo si está vacío
postrotate: ejecutar un comando tras la rotación

7.4 Ejercicio 1 – Rotación de un registro personalizado

Objetivo:

Rotar /var/log/rsync_backup.log cada semana, guardar 4 versiones comprimidas.

Crear el archivo /etc/logrotate.d/rsync_backup:

sudo nano /etc/logrotate.d/rsync_backup

Contenido:

/var/log/rsync_backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Probar la configuración:

sudo logrotate /etc/logrotate.conf --debug

Forzar la rotación para probar:

sudo logrotate /etc/logrotate.conf --force

Verificar:

ls -lh /var/log/rsync_backup*

7.5 Ejercicio 2 – Rotación con reinicio de servicio

Objetivo:

Rotar /var/log/webapp.log y reiniciar el servicio webapp.

Crear el archivo:

sudo nano /etc/logrotate.d/webapp

Contenido:

/var/log/webapp.log {
    weekly
    rotate 2
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

Forzar una rotación para probar:

sudo logrotate -f /etc/logrotate.conf

7.6 Ejercicio 3 – Rotación y envío por correo (simulación)

Objetivo:

Enviar las últimas 100 líneas del archivo /var/log/syslog cada noche a medianoche por correo.

Añadir en la crontab:

crontab -e

Contenido:

0 0 * * * tail -n 100 /var/log/syslog | mail -s "Últimos logs del sistema" sudireccion@email.com

Para probar el envío localmente:

mail

Requisito: el sistema debe tener un agente de correo instalado (mailutils, sendmail, postfix...).

7.7 Ejercicio 4 – Rotación personalizada de un archivo simulado

Cree un registro falso:

echo "línea de prueba" >> /tmp/test.log

Cree el archivo /etc/logrotate.d/testlog:

sudo nano /etc/logrotate.d/testlog

Contenido:

/tmp/test.log {
    daily
    rotate 3
    compress
    missingok
    notifempty
}

Forzar la rotación:

sudo logrotate -f /etc/logrotate.conf

Observar los archivos:

ls -lh /tmp/test.log*

7.8 Resumen

logrotate gestiona el tamaño, la frecuencia, la conservación y la compresión de los logs
Se integra perfectamente con cron (vía /etc/cron.daily/logrotate)
Puede reiniciar servicios o enviar correos
Los archivos de configuración personalizados van en /etc/logrotate.d/

Parte 8 – Quiz Final y Evaluación Práctica

8.1 Objetivo pedagógico

Validar que el estudiante sabe:

Crear, activar y supervisar un servicio systemd personalizado
Planificar tareas repetitivas y puntuales con cron y at
Sincronizar carpetas con rsync y limitar el ancho de banda
Gestionar la rotación de logs con logrotate
Usar las herramientas de supervisión adecuadas (systemctl, journalctl, logrotate, etc.)

8.2 Parte A – Lectura y análisis de `crontab` (5 puntos)

Explique qué hace cada línea siguiente:

0 3 * * 0 /usr/local/bin/backup.sh
*/10 9-17 * * 1-5 who >> /var/log/connected.log
@reboot systemctl restart nginx
0 19 * * * /home/user/sync.sh
0 7 * * * pkill rsync

8.3 Parte B – Creación de servicio systemd (15 puntos)

Debe crear un servicio llamado weather_logger que:

Ejecuta un script /usr/local/bin/weather.sh
Escribe la temperatura en /var/log/weather.log cada 5 minutos (vía cron)
El servicio debe reiniciarse automáticamente en caso de fallo
Proporcionar el archivo weather_logger.service
Activar e iniciar el servicio
Verificar su estado y sus logs

8.4 Parte C – Planificación diferida con `at` (5 puntos)

Cree un script /home/user/alert.sh que envíe un mensaje "Test de seguridad terminado" en un archivo /tmp/alerta.log.
Programe este script para que se ejecute en 2 horas exactamente a partir de ahora.

8.5 Parte D – Sincronización `rsync` (10 puntos)

Cree un script sync_project.sh que:

Realiza una copia de seguridad de la carpeta /home/user/projects/ en /mnt/sauvegardes/
Elimina los archivos obsoletos (--delete)
Limita el ancho de banda a 150 KB/s
Registra las acciones en /var/log/sync.log

Programe este script para que se ejecute todas las noches a las 22h.

8.6 Parte E – Rotación de logs con `logrotate` (10 puntos)

Cree un archivo de configuración /etc/logrotate.d/weather para el archivo /var/log/weather.log
Requisitos:
- Rotación semanal
- 3 archivos conservados
- Compresión activada
- Rotación incluso si está vacío
- Reinicio del servicio weather_logger tras la rotación

8.7 Parte F – Estudio de caso final: escenario completo (15 puntos)

Contexto: Usted gestiona un servidor Linux en el que se ejecuta una aplicación personalizada (/usr/local/bin/monitor.py).

Objetivos:

Crear un servicio monitor.service que ejecute este script al arrancar el sistema.
Planificar una copia de seguridad del directorio /opt/monitoring todos los días a la 1h en /mnt/monitor_backup con rsync, limitada a 250 KB/s.
Crear un archivo /etc/logrotate.d/monitoring.log para /var/log/monitoring.log, con rotación cada 2 días, conservación de 5 logs comprimidos.
Enviar las últimas 100 líneas de /var/log/syslog por correo cada mañana a las 6h a admin@example.com.

8.8 Baremo (sobre 60 puntos)

Parte	Puntos
A – Análisis de crontab	5
B – Servicio systemd	15
C – Planificación con `at`	5
D – Script rsync	10
E – logrotate personalizado	10
F – Caso completo	15

8.9 Instrucciones finales

Todos los scripts deben ser ejecutables (chmod +x)
Las rutas deben ser absolutas
Debe mostrar la salida de:
- systemctl status
- journalctl -u
- ls -lh en los directorios de logs y copias de seguridad

Capítulo creado el: Diciembre 2024

Objetivos de Aprendizaje
1.1 Definición: ¿Qué es un demonio?
- Ejemplos simples:
1.2 Definición Técnica: Naturaleza y Función de un Demonio
1.3 ¿Cómo se crean los demonios?
- 3 pasos:
1.4 Los nombres de los demonios terminan en d
1.5 Lista de demonios comunes en Linux
1.6 Demonios vs Servicios
- A recordar:
1.7 Control de los demonios
1.8 En Resumen – Puntos Clave a Recordar
2.1 ¿Qué es systemd?
- Ventajas de systemd:
2.2 El rol de systemctl
2.3 Comandos fundamentales con systemctl
2.4 Visualización de los servicios
2.5 Uso de journalctl para consultar los logs
2.6 Las unidades (units) en systemd
2.7 Los objetivos (targets) de systemd
2.8 Análisis del rendimiento de arranque
2.9 Gestionar los reinicios automáticos
2.10 Resumen
3.1 Objetivo de esta parte
3.2 Estructura de un archivo .service
- Ejemplo de archivo webapp.service:
- Explicación de las secciones:
3.3 Pasos para crear un servicio systemd personalizado
- Paso 1 – Escribir o localizar el script a ejecutar
- Paso 2 – Crear la unidad de servicio
- Paso 3 – Activar e iniciar el servicio
- Paso 4 – Verificar el correcto funcionamiento
3.4 Modificar un servicio ya existente
3.5 Eliminar un servicio personalizado
3.6 Caso práctico: Reinicio automático de un script que falla
3.7 Caso práctico: Servicio temporal no persistente
3.8 Resumen
- Verificar que el servicio está funcionando y escribiendo en el log
- Ver el PID del servicio
- Matar el proceso con kill (SIGTERM)
- Más agresivo: kill -9 (SIGKILL)
- Prueba en directo
- La solución: detener vía systemd
- Recordatorio: señales y herramientas
- Paso 1 – Verificación del servicio y del log
- Paso 2 – Intento de detención manual (kill)
- Paso 3 – Intento más agresivo (kill -9)
- Paso 4 – Prueba en directo (journalctl)
- Paso 5 – Identificación del servicio (si partimos del proceso)
- Paso 6 – Solución: detención y desactivación vía systemd
- Herramientas complementarias (bonus) – Investigación y diagnóstico
- Síntesis (tipo examen)
4.1 Introducción
4.2 Estructura de una tarea cron
4.3 Truco para practicar rápidamente
4.4 Ejercicio 1 – Copia de seguridad de /etc todos los domingos a las 3h
- Objetivo:
- Pasos:
4.5 Ejercicio 2 – Diviértase con texto
- Objetivo:
- Comando en la crontab:
4.6 Ejercicio 3 – Crear una página web dinámica que cambie cada minuto
- Objetivo:
- Pasos:
4.7 Ejercicio 4 – Observar los procesos y los usuarios
- Objetivo:
- Añadir a la crontab:
4.8 Truco: probar sus tareas cron en directo
4.9 Resumen
5.1 ¿Qué es at?
5.2 Verificación e instalación del servicio atd
5.3 Sintaxis básica
5.4 Ejercicio 1 – Planificar un mensaje diferido
- Objetivo:
5.5 Ejercicio 2 – Script diferido en otra terminal
- Objetivo:
5.6 Gestión de tareas at
5.7 Control de acceso a at
- Ejemplo: prohibir a toto
5.8 Ejercicio 3 – Planificar un reinicio el viernes a las 17h
- Objetivo:
5.9 Ejercicio 4 – Script automático en 2 días
5.10 Resumen
6.1 ¿Por qué usar rsync?
6.2 Sintaxis básica
6.3 Ejercicio 1 – Copia de seguridad local con limitación de ancho de banda
- Objetivo:
- Pasos:
6.4 Ejercicio 2 – Sincronización remota
- Objetivo:
6.5 Ejercicio 3 – Copia de seguridad solo por la noche
- Objetivo:
- Pasos:
6.6 Ejercicio 4 – Copia de seguridad con registro
6.7 Resumen
7.1 ¿Por qué usar logrotate?
7.2 Funcionamiento general
7.3 Sintaxis de un archivo de configuración
- Ejemplo:
- Explicaciones:
7.4 Ejercicio 1 – Rotación de un registro personalizado
- Objetivo:
7.5 Ejercicio 2 – Rotación con reinicio de servicio
- Objetivo:
7.6 Ejercicio 3 – Rotación y envío por correo (simulación)
- Objetivo:
7.7 Ejercicio 4 – Rotación personalizada de un archivo simulado
7.8 Resumen
8.1 Objetivo pedagógico
8.2 Parte A – Lectura y análisis de crontab (5 puntos)
8.3 Parte B – Creación de servicio systemd (15 puntos)
8.4 Parte C – Planificación diferida con at (5 puntos)
8.5 Parte D – Sincronización rsync (10 puntos)
8.6 Parte E – Rotación de logs con logrotate (10 puntos)
8.7 Parte F – Estudio de caso final: escenario completo (15 puntos)
8.8 Baremo (sobre 60 puntos)
8.9 Instrucciones finales

Objetivos de Aprendizaje​

Parte 1 – Introducción a Demonios y Servicios

1.1 Definición: ¿Qué es un demonio?​

Ejemplos simples:​

1.2 Definición Técnica: Naturaleza y Función de un Demonio​

1.3 ¿Cómo se crean los demonios?​

3 pasos:​

1.4 Los nombres de los demonios terminan en d​

1.5 Lista de demonios comunes en Linux​

1.6 Demonios vs Servicios​

Un servicio es simplemente systemd​

A recordar:​

1.7 Control de los demonios​

1.8 En Resumen – Puntos Clave a Recordar​

Parte 2 – Introducción a systemd y systemctl

2.1 ¿Qué es systemd?​

Ventajas de systemd:​

2.2 El rol de systemctl​

2.3 Comandos fundamentales con systemctl​

2.4 Visualización de los servicios​

2.5 Uso de journalctl para consultar los logs​

2.6 Las unidades (units) en systemd​

2.7 Los objetivos (targets) de systemd​

2.8 Análisis del rendimiento de arranque​

2.9 Gestionar los reinicios automáticos​

2.10 Resumen​

Parte 3 – Crear y Gestionar sus Propios Servicios con systemd

3.1 Objetivo de esta parte​

3.2 Estructura de un archivo .service​

Ejemplo de archivo webapp.service:​

Explicación de las secciones:​

3.3 Pasos para crear un servicio systemd personalizado​

Paso 1 – Escribir o localizar el script a ejecutar​

Paso 2 – Crear la unidad de servicio​

Paso 3 – Activar e iniciar el servicio​

Paso 4 – Verificar el correcto funcionamiento​

3.4 Modificar un servicio ya existente​

3.5 Eliminar un servicio personalizado​

3.6 Caso práctico: Reinicio automático de un script que falla​

3.7 Caso práctico: Servicio temporal no persistente​

3.8 Resumen​

Verificar que el servicio está funcionando y escribiendo en el log​

Ver el PID del servicio​

Matar el proceso con kill (SIGTERM)​

Más agresivo: kill -9 (SIGKILL)​

Prueba en directo​

La solución: detener vía systemd​

Recordatorio: señales y herramientas​

Paso 1 – Verificación del servicio y del log​

Paso 2 – Intento de detención manual (kill)​

Paso 3 – Intento más agresivo (kill -9)​

Paso 4 – Prueba en directo (journalctl)​

Paso 5 – Identificación del servicio (si partimos del proceso)​

Paso 6 – Solución: detención y desactivación vía systemd​

Herramientas complementarias (bonus) – Investigación y diagnóstico​

1. systemd-cgls — Árbol de grupos de control (cgroups)​

2. ss -lptn — Puertos TCP en escucha y procesos​

3. fuser -k 3000/tcp — Matar procesos que usan un puerto​

4. journalctl -u webapp — Logs del servicio (equivalente a journalctl -u wikijs.service)​

Síntesis (tipo examen)​

Parte 4 – Planificación de Tareas con cron

4.1 Introducción​

4.2 Estructura de una tarea cron​

4.3 Truco para practicar rápidamente​

4.4 Ejercicio 1 – Copia de seguridad de /etc todos los domingos a las 3h​

Objetivo:​

Pasos:​

4.5 Ejercicio 2 – Diviértase con texto​

Objetivo:​

Comando en la crontab:​

4.6 Ejercicio 3 – Crear una página web dinámica que cambie cada minuto​

Objetivo:​

Pasos:​

4.7 Ejercicio 4 – Observar los procesos y los usuarios​

Objetivo:​

Añadir a la crontab:​

4.8 Truco: probar sus tareas cron en directo​

4.9 Resumen​

Parte 5 – Tareas Puntuales con at

5.1 ¿Qué es at?​

Objetivos de Aprendizaje

1.1 Definición: ¿Qué es un demonio?

Ejemplos simples:

1.2 Definición Técnica: Naturaleza y Función de un Demonio

1.3 ¿Cómo se crean los demonios?

3 pasos:

1.4 Los nombres de los demonios terminan en `d`

1.5 Lista de demonios comunes en Linux

1.6 Demonios vs Servicios

Un servicio es simplemente systemd

A recordar:

1.7 Control de los demonios

1.8 En Resumen – Puntos Clave a Recordar

2.1 ¿Qué es systemd?

Ventajas de systemd:

2.2 El rol de `systemctl`

2.3 Comandos fundamentales con `systemctl`

2.4 Visualización de los servicios

2.5 Uso de `journalctl` para consultar los logs

2.6 Las unidades (`units`) en systemd

2.7 Los objetivos (`targets`) de systemd

2.8 Análisis del rendimiento de arranque

2.9 Gestionar los reinicios automáticos

2.10 Resumen

3.1 Objetivo de esta parte

3.2 Estructura de un archivo `.service`

Ejemplo de archivo `webapp.service`:

Explicación de las secciones:

3.3 Pasos para crear un servicio systemd personalizado

Paso 1 – Escribir o localizar el script a ejecutar

Paso 2 – Crear la unidad de servicio

Paso 3 – Activar e iniciar el servicio

Paso 4 – Verificar el correcto funcionamiento

3.4 Modificar un servicio ya existente

3.5 Eliminar un servicio personalizado

3.6 Caso práctico: Reinicio automático de un script que falla

3.7 Caso práctico: Servicio temporal no persistente

3.8 Resumen

Verificar que el servicio está funcionando y escribiendo en el log

Ver el PID del servicio

Matar el proceso con kill (SIGTERM)

Más agresivo: kill -9 (SIGKILL)

Prueba en directo

La solución: detener vía systemd

Recordatorio: señales y herramientas

Paso 1 – Verificación del servicio y del log

Paso 2 – Intento de detención manual (kill)

Paso 3 – Intento más agresivo (kill -9)

Paso 4 – Prueba en directo (journalctl)

Paso 5 – Identificación del servicio (si partimos del proceso)

Paso 6 – Solución: detención y desactivación vía systemd

Herramientas complementarias (bonus) – Investigación y diagnóstico

1. `systemd-cgls` — Árbol de grupos de control (cgroups)

2. `ss -lptn` — Puertos TCP en escucha y procesos

3. `fuser -k 3000/tcp` — Matar procesos que usan un puerto

4. `journalctl -u webapp` — Logs del servicio (equivalente a `journalctl -u wikijs.service`)

Síntesis (tipo examen)

4.1 Introducción

4.2 Estructura de una tarea cron

4.3 Truco para practicar rápidamente

4.4 Ejercicio 1 – Copia de seguridad de /etc todos los domingos a las 3h

Objetivo:

Pasos:

4.5 Ejercicio 2 – Diviértase con texto

Objetivo:

Comando en la crontab:

4.6 Ejercicio 3 – Crear una página web dinámica que cambie cada minuto

Objetivo:

Pasos:

4.7 Ejercicio 4 – Observar los procesos y los usuarios

Objetivo:

Añadir a la crontab:

4.8 Truco: probar sus tareas cron en directo

4.9 Resumen

Parte 5 – Tareas Puntuales con `at`

5.1 ¿Qué es `at`?

5.2 Verificación e instalación del servicio `atd`

5.3 Sintaxis básica

5.4 Ejercicio 1 – Planificar un mensaje diferido

Objetivo: