Introduction
DAYMARK dispose déjà d’un script de publication sûr dans ce nouvel environnement. L’équipe a maintenant besoin d’une véritable planification exécutée sous un compte dédié aux rapports. Une réussite manuelle dans votre terminal ne prouve pas qu’une tâche planifiée trouve ou lise son entrée.
Vous configurerez un service et un timer systemd correspondants, observerez des déclenchements réels répétés, puis corrigerez des erreurs de répertoire et d’entrée sans perdre le dernier rapport. Daymark est le site métier ; Workstation commence dans /srv/daymark-sales. Les bases du terminal suffisent ; les notions du script shell de l’atelier précédent sont réutilisées. Le calculateur et le script fournis ne nécessitent aucune installation.
Exécuter l’export depuis un vrai timer
Dans cette étape, vous établirez le résultat métier correct et laisserez systemd exécuter l’export deux fois. Commencez dans Daymark. Ouvrez Records : la source initiale contient 11 articles d’une valeur de 3450 centimes. Reports propose encore la clôture précédente, TOTAL,1,100. La tâche doit remplacer ce fichier par la véritable clôture.
Passez à Workstation. Cet environnement est indépendant : le script correct est préparé, mais aucun timer de rapports n’est installé. cat affiche les fichiers ; pwd affiche votre répertoire courant :
pwd
cat publish.sh
Le script écrit à côté de la destination et ne renomme qu’après un calcul réussi. Il accepte des arguments d’entrée et de sortie. id affiche l’identité du compte ; ls -ld affiche le propriétaire et les bits de permission du répertoire. Il faut le droit de recherche pour traverser un répertoire et le droit d’écriture pour y créer des fichiers.
id daymark-report
ls -ld reports
Le compte système préparé possède reports/. La lecture de l’entrée et la recherche dans les répertoires parents lui permettent de lire orders.csv ; la propriété du répertoire des rapports autorise la publication. N’utilisez ni root ni l’écriture pour tous comme raccourci.
systemd est le gestionnaire de services de cette instance. Un fichier .service décrit une exécution ; son .timer de même nom indique quand la demander. Type=oneshot attend la fin de cette tâche finie. User choisit le compte réel d’exécution. WorkingDirectory détermine où le chemin relatif orders.csv est résolu. ExecStart utilise des chemins absolus pour l’exécutable, le script et la sortie. Le répertoire du terminal et ses réglages shell interactifs ne sont pas transmis à un service système. Laissez RemainAfterExit non défini : la tâche terminée doit devenir inactive pour qu’un autre événement du timer puisse la relancer.
sudo tee FILE écrit un fichier protégé tout en l’affichant. <<'UNIT' est un here-document entre guillemets ; collez jusqu’au mot de fin correspondant. Créez uniquement les unités D10 indiquées :
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
Ce timer de formation commence cinq secondes après son activation et demande une autre exécution vingt secondes après l’activation précédente. AccuracySec=1s autorise une petite fenêtre de planification ; la machine peut ajouter du retard. Il s’agit d’une répétition courte, pas d’un horaire quotidien de production. Une planification quotidienne à heure fixe pourrait remplacer ces deux directives relatives par OnCalendar=*-*-* 23:00:00, avec un fuseau horaire du serveur choisi délibérément. Nous conservons ici le rythme court pour observer de vraies exécutions.
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 relit les définitions des unités. enable --now rattache ce timer à timers.target pour les prochains démarrages et le lance immédiatement. Il lance le timer, pas un export manuel :
sudo systemctl daemon-reload
sudo systemctl enable --now d10-sales.timer
sleep 50 attend sans exécuter la tâche. Ne démarrez pas le service manuellement et ne remplacez pas le timer par une boucle shell.
sleep 50
list-timers affiche les déclenchements réels LAST et NEXT. --no-pager imprime directement au lieu d’ouvrir un visualiseur défilant :
systemctl list-timers d10-sales.timer --no-pager
Le journal contient les véritables événements systemd. -u sélectionne cette unité et -n 20 limite la sortie. Il doit montrer au moins deux exécutions complètes, avec uid=... cwd=/srv/daymark-sales, une empreinte du rapport et une fin réussie :
sudo journalctl -u d10-sales.service -n 20 --no-pager
Comparez l’uid numérique à id daymark-report. inactive (dead) après un oneshot réussi est normal ; un timer actif demande les exécutions futures. show -p sélectionne certaines propriétés d’état :
systemctl show d10-sales.service -p User -p WorkingDirectory -p Result -p ExecMainStatus --no-pager
Vous devez voir User=daymark-report, le bon répertoire, Result=success et ExecMainStatus=0. Si aucun déclenchement n’apparaît, lisez systemctl status d10-sales.timer --no-pager ; corrigez uniquement ces fichiers d’unités, relancez daemon-reload, puis redémarrez seulement d10-sales.timer. restart arrête et relance ce timer pour appliquer ses modifications. Attendez puis consultez encore le journal. Pour CHDIR, vérifiez WorkingDirectory ; pour Permission denied, examinez la propriété de l’entrée et du répertoire des rapports plutôt que d’élargir les permissions.
Revenez dans Daymark, rechargez Reports et téléchargez le nouveau CSV. Son total est TOTAL,11,3450. Rouvrez Records et revenez à l’accueil ; les pages métier normales restent disponibles.
Reprendre au prochain déclenchement planifié
Dans cette étape, vous observerez de vrais échecs planifiés, conserverez le rapport précédent, puis publierez une nouvelle clôture après reprise. Commencez dans Workstation. Travaillez uniquement sur les unités D10 et l’entrée de cet exercice ; n’arrêtez jamais les services sans rapport.
Créez d’abord une erreur de répertoire de travail. sed -i modifie sur place le fichier nommé ; s|old|new| remplace le texte correspondant. C’est une panne volontaire :
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
Le processus utilise toujours le compte de rapports, mais orders.csv est résolu dans /tmp et échoue avec Export failed: ... No such file .... Si le répertoire de travail lui-même manquait, CHDIR surviendrait avant l’exécution du script. daemon-reload met à jour les définitions, sans lancer la tâche. Le timer a provoqué cette tentative échouée.
cat reports/sales.csv
Le rapport doit toujours se terminer par TOTAL,11,3450. Dans Daymark, rechargez Reports et téléchargez-le pour confirmer que les mêmes octets restent utilisables. Revenez dans Workstation et corrigez le répertoire :
sudo sed -i 's|WorkingDirectory=/tmp|WorkingDirectory=/srv/daymark-sales|' /etc/systemd/system/d10-sales.service
sudo systemctl daemon-reload
Exercez maintenant une erreur d’entrée. cp copie un jeu malformé préparé uniquement sur orders.csv ; le calculateur doit retourner un état non nul et le script doit laisser le dernier rapport intact :
cp fixtures/broken.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
Vous devez voir l’échec volontaire lié au nombre invalide. show expose le véritable dernier code de sortie, indépendamment de la réussite de la commande de consultation du journal :
systemctl show d10-sales.service -p Result -p ExecMainStatus --no-pager
Vous devez obtenir Result=exit-code et ExecMainStatus=1. Confirmez que le rapport précédent subsiste :
cat reports/sales.csv
Restaurez une nouvelle clôture valide avec deux Tea supplémentaires. La reprise doit actualiser le total à 13 articles et 3950 centimes au prochain déclenchement :
cp fixtures/next.csv orders.csv
sleep 30
sudo journalctl -u d10-sales.service -n 15 --no-pager
cat reports/sales.csv
Vous devez voir Tea,5,1250 et TOTAL,13,3950, avec une publication réelle ultérieure dans le journal. Si le rapport reste ancien, lisez la dernière erreur, corrigez le répertoire, l’orthographe de l’entrée ou le script, puis attendez un nouvel événement. Ne remplacez pas le CSV à la main et ne lancez pas le service manuellement. Le oneshot échoué peut être exécuté à nouveau par ce timer.
Dans Daymark, rechargez Records et Reports ; téléchargez encore et comparez la source modifiée à TOTAL,13,3950. Gardez le timer actif pour l’évaluation. Cet exercice ne teste pas la reprise après redémarrage, la politique de fuseau horaire, la concurrence entre machines ou la comptabilisation des jours manqués.
Résumé
Vous avez pratiqué la publication complète de CSV, les états d’échec significatifs et la reprise. Un rapport planifié n’est utile que si son identité réelle d’exécution, son déclenchement et ses totaux métier concordent. Cet exercice sur une seule instance utilise des données fictives et un intervalle court de formation ; ce n’est pas une plateforme complète de reporting de production.
