Introducción
DAYMARK ya dispone de un script publicador seguro en este entorno nuevo. Ahora el equipo necesita una programación real bajo una cuenta dedicada a informes. El éxito manual en tu terminal no demuestra que una tarea programada pueda encontrar o leer su entrada.
Configurarás un servicio y un temporizador systemd correspondientes, observarás activaciones reales repetidas y te recuperarás de fallos de directorio y entrada sin perder el último informe. Daymark es el sitio del negocio; Workstation empieza en /srv/daymark-sales. Basta el uso básico del terminal; se reutilizan los conceptos del script de shell del laboratorio guiado anterior. El calculador y el script proporcionados no requieren instalación.
Ejecutar la exportación desde un temporizador real
En este paso establecerás el resultado correcto del negocio y dejarás que systemd ejecute dos exportaciones. Empieza en Daymark. Abre Records: el origen inicial contiene 11 unidades por 3450 céntimos. Reports todavía ofrece el cierre anterior, TOTAL,1,100. La tarea debe sustituir ese archivo por el cierre real.
Cambia a Workstation. Este entorno es independiente: el script correcto ya está preparado, pero no hay ningún temporizador de informes instalado. cat imprime archivos y pwd muestra el directorio actual:
pwd
cat publish.sh
El script escribe junto al destino y renombra solo después de calcular correctamente. Acepta argumentos de entrada y salida. id muestra la identidad de la cuenta; ls -ld muestra propietario y permisos del directorio. Un directorio requiere permiso de búsqueda para atravesarlo y de escritura para crear archivos.
id daymark-report
ls -ld reports
La cuenta de sistema preparada es propietaria de reports/. El permiso de lectura de la entrada y de búsqueda de los directorios superiores le permiten leer orders.csv; ser propietaria del directorio de informes permite publicar. No uses root ni escritura para todos como atajo.
systemd es el gestor de servicios de esta instancia. Un archivo .service describe una ejecución; su .timer del mismo nombre indica cuándo solicitarla. Type=oneshot espera a que termine esta tarea finita. User selecciona la cuenta real de ejecución. WorkingDirectory determina dónde se resuelve el orders.csv relativo. ExecStart utiliza rutas absolutas para ejecutable, script y salida. El directorio del terminal y su configuración interactiva de shell no se transfieren a un servicio del sistema. Deja RemainAfterExit sin definir: la tarea terminada debe quedar inactiva para que el próximo evento vuelva a ejecutarla.
sudo tee FILE escribe un archivo protegido y también lo imprime. <<'UNIT' es un here-document entre comillas; pega hasta la palabra de cierre correspondiente. Crea solo las unidades D10 indicadas:
sudo tee /etc/systemd/system/d10-sales.service <<'UNIT'
[Unit]
Description=Daymark sales export
[Service]
Type=oneshot
User=daymark-report
WorkingDirectory=/srv/daymark-sales
ExecStart=/bin/bash /srv/daymark-sales/publish.sh orders.csv /srv/daymark-sales/reports/sales.csv
UNIT
Este temporizador de entrenamiento empieza cinco segundos después de activarse y solicita otra ejecución veinte segundos después de la activación anterior. AccuracySec=1s permite una pequeña ventana de programación; la máquina puede añadir retraso. Es un ensayo corto, no una programación diaria de producción. Un horario diario de reloj podría usar OnCalendar=*-*-* 23:00:00 en lugar de estas dos directivas relativas, eligiendo deliberadamente la zona horaria del servidor. Aquí mantenemos el intervalo corto para observar ejecuciones reales.
sudo tee /etc/systemd/system/d10-sales.timer <<'UNIT'
[Unit]
Description=Daymark short training schedule
[Timer]
OnActiveSec=5s
OnUnitActiveSec=20s
AccuracySec=1s
[Install]
WantedBy=timers.target
UNIT
daemon-reload vuelve a leer las definiciones de unidades. enable --now conecta este temporizador con timers.target para futuros arranques y lo inicia ahora. Inicia el temporizador, no una exportación manual:
sudo systemctl daemon-reload
sudo systemctl enable --now d10-sales.timer
sleep 50 espera sin ejecutar la tarea. No inicies manualmente el servicio ni sustituyas el temporizador por un bucle de shell.
sleep 50
list-timers muestra las activaciones reales LAST y NEXT. --no-pager imprime directamente sin abrir un visor con desplazamiento:
systemctl list-timers d10-sales.timer --no-pager
El journal es el registro real de eventos de systemd. -u selecciona esta unidad y -n 20 limita la salida. Debe contener al menos dos ejecuciones completas, con uid=... cwd=/srv/daymark-sales, un hash del informe y finalización correcta:
sudo journalctl -u d10-sales.service -n 20 --no-pager
Compara el uid numérico con id daymark-report. Es normal que un oneshot correcto muestre inactive (dead) al terminar; un temporizador activo solicita futuras ejecuciones. show -p selecciona propiedades concretas del estado:
systemctl show d10-sales.service -p User -p WorkingDirectory -p Result -p ExecMainStatus --no-pager
Espera User=daymark-report, el directorio correcto, Result=success y ExecMainStatus=0. Si no hay activación, lee systemctl status d10-sales.timer --no-pager; corrige solo estos archivos, repite daemon-reload y reinicia únicamente d10-sales.timer. restart detiene e inicia ese temporizador para aplicar sus cambios. Espera otra vez y revisa el journal. Para CHDIR, revisa WorkingDirectory; ante Permission denied, examina la propiedad de la entrada y del directorio de informes sin ampliar permisos.
Vuelve a Daymark, recarga Reports y descarga el CSV nuevo. Su total es TOTAL,11,3450. Abre Records otra vez y vuelve al inicio; las páginas normales del negocio siguen disponibles.
Recuperar mediante la siguiente ejecución programada
En este paso observarás fallos programados reales, conservarás el informe anterior y publicarás un cierre nuevo tras recuperarte. Empieza en Workstation. Trabaja solo sobre las unidades D10 y la entrada de este ejercicio; nunca detengas servicios ajenos.
Primero provoca un error de directorio de trabajo. sed -i edita el archivo indicado en su lugar; s|old|new| sustituye el texto coincidente. Es un fallo intencionado:
sudo sed -i 's|WorkingDirectory=/srv/daymark-sales|WorkingDirectory=/tmp|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
El proceso sigue bajo la cuenta de informes, pero orders.csv se resuelve en /tmp y falla con Export failed: ... No such file .... Si faltara el propio directorio de trabajo, aparecería CHDIR antes de ejecutar el script. daemon-reload actualiza definiciones, no ejecuta la tarea. Este intento fallido lo provocó el temporizador.
cat reports/sales.csv
Debe seguir terminando en TOTAL,11,3450. En Daymark, recarga Reports y descarga para confirmar que los mismos bytes siguen utilizables. Vuelve a Workstation y corrige el directorio:
sudo sed -i 's|WorkingDirectory=/tmp|WorkingDirectory=/srv/daymark-sales|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
Ahora prueba un fallo de entrada. cp copia un fixture mal formado preparado sobre únicamente orders.csv; el calculador debe devolver un estado no nulo y el script debe conservar intacto el último informe:
cp fixtures/broken.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
Espera el fallo intencionado por número inválido. show expone el último estado de salida real, independientemente del éxito del comando que muestra el journal:
systemctl show d10-sales.service -p Result -p ExecMainStatus --no-pager
Espera Result=exit-code y ExecMainStatus=1. Confirma que permanece el informe anterior:
cat reports/sales.csv
Restaura un cierre válido nuevo con dos Tea adicionales. En la siguiente activación, la recuperación debe actualizar el total a 13 unidades y 3950 céntimos:
cp fixtures/next.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
cat reports/sales.csv
Espera Tea,5,1250 y TOTAL,13,3950, con una publicación real posterior en el journal. Si permanece antiguo, lee el error más reciente, corrige directorio, nombre de entrada o script y espera otro evento del temporizador. No sustituyas el CSV a mano ni inicies manualmente el servicio. El oneshot fallido puede volver a ejecutarse con este temporizador.
En Daymark, recarga Records y Reports; descarga nuevamente y compara el origen cambiado con TOTAL,13,3950. Mantén activo el temporizador para la evaluación. Este ejercicio no prueba recuperación tras reinicios, política horaria, concurrencia entre máquinas ni contabilidad de días omitidos.
Resumen
Has practicado la publicación completa de CSV, estados de fallo significativos y recuperación. Un informe programado solo es útil cuando coinciden su identidad de ejecución real, su activación y los totales del negocio. Este ejercicio de una sola instancia usa datos ficticios y un intervalo de entrenamiento corto; no es una plataforma completa de informes de producción.
