Cron de nouvelle génération avec systemd créant une minuterie

Avez-vous besoin de planifier une tâche à l'avenir sur votre ordinateur? Cela peut sembler simple - après tout, votre lave-vaisselle est capable d'attendre avant de démarrer à l'aide d'un bouton - mais parfois les ordinateurs effectuent des tâches si simples très difficile.Mais si vous avez un peu d'expérience, vous aurez probablement entendu parler de cron, ce logiciel entièrement dédié pour lancer la bonne tâche au bon moment. Mais cet outil a vraiment été conçu dans un souci de simplicité et vous risquez au final d'avoir de mauvaises surprises.Si vous avez déjà réussi à planifier une tâche sous Windows, vous avez utilisé le planificateur de tâches Windows. Il a une interface graphique par défaut mais cela ne le rend pas aussi simple à utiliser: ces deux systèmes lancent simplement un processus à une heure et une date fixes.

Afin de comprendre comment systemd peut vous être utile là-bas, je vais prendre un exemple.

Quels pièges les minuteries systemd vous éviteront?

Si vous possédez déjà une machine contenant des données qui vous intéressent, vous souhaiterez avoir une copie de vos données dans un autre endroit, probablement plus sûr. Si vous gérez un serveur, c'est obligatoire : après tout, comment allez-vous récupérer si votre disque dur tombe en panne et vous empêcher de récupérer des données?

Donc, en tant que personne responsable, vous configurez une sauvegarde chaque semaine ou chaque jour. Vous pouvez le configurer à l'aide de cron, vous le programmez à 4h24, mais ici commence le problème : que se passe-t-il si votre serveur est arrêté de 4h10 à 4h30 pour une raison quelconque?

Eh bien, il est probable que cron ignorera cette sauvegarde. Cela peut être critique si cela se produit souvent et en silence ou si votre code repose sur le fait qu'il s'exécute et qu'il peut échouer autrement. Généralement, cela se produit lorsque vous configurez une tâche de nettoyage via cron et qu'elle ne se lance pas. Soudain, votre code peut avoir un espace insuffisant pour continuer et se brisera - c'est triste, si triste situation, n'est-ce pas M. Elton John.

Cependant, si un lancement manqué peut être un problème, imaginez une seconde - wow, John Lennon maintenant? - que votre tâche est trop lente. Si votre tâche est configurée pour s'exécuter toutes les 10 minutes mais prend 15 minutes pour se terminer, cron ou Windows lancera volontiers une autre tâche même si la tâche en cours n'est pas encore partie - et donc, vous aurez 2 instances de votre tâche en cours d'exécution simultanément , qui est le recette parfaite pour catastrophe. Lorsqu'un programme s'exécute simultanément alors qu'il n'est pas conçu pour le faire, il corrompt très probablement des fichiers, d'autres logiciels, des bases de données - et votre serveur devient soudainement un navire en train de couler comme le Titanic.

OK, peut-être que je vais trop loin avec Titanic mais vous voyez l'idée. Bien que systemd n'ait pas pu faire grand-chose pour sauver ce vaisseau, il peut vous aider avec toutes ces lacunes et vous assurer des vacances de Noël plus longues grâce aux bugs qu'il vous évitera. Il est temps maintenant d'apprendre à configurer les minuteries systemd.

Comment planifier une sauvegarde de serveur automatisée?

Tout d'abord, les minuteurs systemd déclenchent un service systemd, donc avant de planifier votre tâche, vous devrez d'abord en faire un service. Heureusement, j'ai écrit un guide pour créer le service systemd, de cette façon il vous présentera la façon de travailler de systemd. Tu devrais le lire avant de continuer. Sauf si vous exactement savoir ce que vous faites, votre fichier de service systemd devrait ne pas contenir tout paramètre WantedBy=. Si vous souhaitez démarrer votre service à une heure précise, vous ne voudrez probablement pas le démarrer au démarrage.

Grâce au système de service systemd, il est impossible d'avoir plusieurs instances de votre tâche en cours d'exécution par erreur : si une tâche est déjà en cours d'exécution, elle ignorera simplement ce lancement et laissera la tâche en cours d'exécution terminer son travail.

Une fois que vous avez un service systemd à planifier, créez un fichier avec le même nom de fichier que votre service, sauf qu'il doit se terminer par .minuterie au lieu de .un service. Dans notre exemple de sauvegarde automatisée, le service serait une sauvegarde automatisée.service et la minuterie serait une sauvegarde automatisée.minuteur. Les deux fichiers doivent être dans le même répertoire. Comme je vous l'ai dit dans l'article du service systemd, je vous recommande d'écrire ces fichiers dans un endroit normal tel que votre répertoire personnel, puis de les copier dans un dossier systemd, une fois que vous avez terminé vos modifications.

Alors, laissez-moi vous montrer à quoi ressemble notre fichier de minuterie :

[Unité]
Description=Planifier des sauvegardes pendant les heures creuses
[Minuteur]
SurCalendrier=*-*-* 03:00:00
RandomizedDelaySec=7200
Persistant=vrai
[Installer]
WantedBy=minuteurs.cible

Tout comme dans les services systemd, il y a 3 sections. [Unit] ou [Install] fonctionnent exactement comme expliqué dans mon article sur les services systemd. Veuillez noter que WantedBy= est important ici car les minuteurs peuvent être démarrés ou arrêtés, donc si vous ne dites pas à systemd de démarrer votre minuteur pendant le démarrage, il ne se déclenchera jamais. minuteries.target est une cible systemd spéciale pour les minuteurs.

Maintenant, la section [Timer]. À l'intérieur, vous trouverez tous les paramètres liés au moment où la minuterie doit se déclencher. Pour notre sauvegarde automatisée, j'ai dit à systemd de l'exécuter entre 3h et 5h du matin au fuseau horaire du serveur. L'heure exacte est aléatoire chaque jour.

OnCalendar= définit la minuterie liée à l'heure de votre serveur (wallclock), comme tous les dimanches à 13h00. Si vous avez déjà utilisé cron, vous devriez être très familier avec cette syntaxe. Cependant, il a des avantages supplémentaires.

Par exemple, si vous voulez que quelque chose se passe toutes les heures, vous pouvez procéder comme ceci :

OnCalendar=horaire

et quotidiennement :

OnCalendar=quotidien

En fait, il prend en charge toutes les valeurs suivantes :

1. minutieusement
2. toutes les heures
3. du quotidien
4. mensuel
5. hebdomadaire
6. annuel
7. trimestriel
8. semestriellement

Il y a cependant un problème avec ces mots-clés : par exemple, le quotidien déclenche toujours un minuit, qui est souvent une heure de pointe dans les systèmes informatiques. C'est pourquoi il est recommandé d'utiliser RandomizedDelaySec= (son utilisation est précisée ci-dessous). De toute façon pour la sauvegarde ce n'est pas une bonne option : minuit ce n'est pas les heures creuses, c'est plutôt l'inverse. Nous devons donc définir plus précisément quand nous voulons voir cette tâche lancée.

Si vous voulez plus de contrôle, vous pouvez écrire une date comme 2018-12-06 12:49:37. Eh bien, si vous êtes si spécifique, vous ne déclencherez la minuterie qu'une seule fois. Pour le rendre récurrent, vous remplacerez n'importe lequel de ces éléments par * astérisque.

SurCalendrier=*-*-* 03:00:00

Comme vous pouvez le voir ci-dessus, dans notre exemple de sauvegarde, toute la partie date est *-*-*, ce qui signifie qu'elle doit se produire chaque jour de chaque mois de chaque année. Maintenant si tu fais :

SurCalendrier=*-12-25 03:00:00

Ensuite, il se déroule tous les 25 décembre à 3 heures du matin. Minuterie système parfaite pour le Père Noël - même si je doute qu'il en ait jamais besoin! Donc l'astérisque ajoute une récurrence là où vous la mettez. Si vous le mettez dans le champ année, cela signifie "chaque année", etc.

Enfin, vous pouvez ajouter UTC à la fin de la ligne pour utiliser l'heure UTC au lieu du fuseau horaire local. Par exemple, certains services réinitialisent leurs quotas d'API à minuit mais pour éviter tout biais de fuseau horaire, ils utilisent UTC. Donc, pour de telles tâches, vous feriez :

OnCalendar = UTC quotidien

Maintenant, résolvons un autre problème : les heures de pointe. systemd a aussi un cadre pour lutter contre ça.

RandomizedDelaySec= permet de retarder la tâche d'un temps aléatoire. La valeur est le nombre maximum de secondes que la minuterie retardera. Il est spécifiquement destiné à de tels cas. Vous vous souvenez que dans systemd, daily se déclenche toujours à minuit? Eh bien, chaque semaine se déclenche toujours le lundi à minuit et chaque année le 1er janvier à minuit, l'un des pires pics de l'année avec des pannes de réseau partout. Vous ne voulez certainement pas que cela se produise.

En ajoutant un délai, vous supprimez ce problème : il retardera automatiquement à une heure inconnue votre tâche. L'aléatoire ici est important car il est beaucoup plus susceptible d'être même lorsqu'il est aléatoire et une charge uniforme permet de mieux optimiser vos tâches.

Supposons que vous deviez exécuter vos tâches vers 7 heures du matin mais que vous souhaitiez autoriser un petit délai de 15 minutes maximum, procédez comme suit :

RandomizedDelaySec=900

Cela devrait suffire pour les retards. Parfois, même des délais de quelques millisecondes suffisent pour éviter les pics involontaires.

Persistant = prend en charge les déclencheurs de minuterie manqués. Que faire si votre serveur est arrêté pendant la nuit? Eh bien, la sauvegarde ne se déclencherait jamais du tout. Le définir sur true permet à systemd de l'exécuter au prochain démarrage dans de tels cas. De cette façon, vous savez d'une manière ou d'une autre, la tâche du minuteur sera exécutée. Son utilisation est simple, il vous suffit de faire ceci :

Persistant=vrai

Cela a cependant un inconvénient qui est vraiment difficile à éviter de toute façon : lorsque plusieurs tâches de différents minuteurs sont manquées, elles s'exécuteront toutes au démarrage et ralentiront ce démarrage. A mon avis c'est bien mieux que s'il ne tourne jamais et après tout c'est normal, le moment le plus approprié pour lancer le timer est quand il est programmé, après ce sera probablement inapproprié de toute façon.

OnBootSec= est la dernière option que je vais vous montrer (mais pas la moindre). C'est si vous voulez déclencher une minuterie quelque temps après le démarrage au lieu de vous baser sur le calendrier. Par exemple, si vous devez vérifier au démarrage si votre serveur est démarré correctement et fonctionne comme prévu, vous pouvez écrire un service de vérification et utiliser ce paramètre de minuterie pour le déclencher une fois que le système a eu suffisamment de temps pour démarrer.

Disons que le système a besoin de 3 minutes pour démarrer, vous pouvez faire :

OnBootSec=180

Et malgré son nom, vous pouvez aussi faire :

OnBootSec=3 minutes

Si vous précisez à la fois OnBootSec= et OnCalendar=, il démarrera le service chaque fois que l'un de ces 2 événements se produira.

D'accord, il est maintenant temps d'enregistrer votre fichier, de le copier dans le dossier système si vous avez suivi mes conseils ci-dessus et de tester si votre minuteur fonctionne correctement.

Activez votre nouvelle minuterie et surveillance

Afin de tester votre nouveau minuteur, vous devez dire à systemd que vous avez ajouté un nouveau minuteur, vous devez donc taper cette commande :

$ sudo systemctl démon-recharger

Maintenant, systemd prendra en compte votre nouveau minuteur et regardera de près quand exécuter votre tâche. Comme systemd est toujours en cours d'exécution, c'est après tout l'un des meilleurs candidats pour gérer et exécuter vos tâches planifiées.

Une chose que vous pourriez trouver contre-intuitive cependant : une minuterie est désactivée par défaut. Pour l'activer, vous devez exécuter cette commande :

$ sudo systemctl enable --now automatic-backup.minuteur

Vous voudrez alors probablement voir si votre minuterie agit comme prévu. Bonne nouvelle : systemd a même la gentillesse d'avoir une commande vous indiquant quand il a été lancé pour la dernière fois et quand le prochain lancement est prévu (sauf si le minuteur est configuré pour ne s'exécuter qu'au démarrage, car systemd ne sait pas quand le système redémarrera, évidemment). Voici cette commande :

$ systemctl status sauvegarde automatique.minuteur

Enfin, lorsque vous n'avez plus besoin du minuteur, vous pouvez également le désactiver :

$ sudo systemctl disable --now automatic-backup.minuteur

Conclusion

En utilisant les minuteries systemd, votre gestion des tâches planifiées passe à un niveau supérieur : honnêtement, j'ai personnellement l'impression que les tâches planifiées auraient dû être ainsi depuis des années.

Oh, une petite surprise pour vous : tous les temporisateurs systemd sont enregistrés dans un système bien structuré avec filtrage, rotation des journaux et tout le reste. Je vous invite donc à voir comment vous pouvez voir les journaux de vos tâches planifiées!