Enhanced cron management¶
Conclusion Seminaire¶
- lock dans fichier (uniquement pour indicateur "en cours")
- Config globale : Nombre de taches à exécuter par passage de cron externe / interne : Toutes / 0 / 1 / 2 / ...
- Description table tache
- ID
- core ou nom_plugin
- nom_tache (generation nom fonction = plugin_toto_cron_titi)
- Nom
- Description
- Fréquence : modifiable par utilisateur
- desactivé
- interne / externe -> appel via cron.php qui détecte si lancé en interne ou externe
- mode forcé (interne ou externe)
- Blacklist horaire : heure debut blacklist / heure fin blacklist
- Durée conservation log pour cette tache : Toujours (0) / 1 / 2 jours....
- Monitoring : date dernière exécution / nombre d'exécution / durée totale / durée min / durée max / Dernier code retour -> Possibilité de faire un reset
- Log en base : ID / tache_ID / date / message
- Plugins : fonction registerCronTask -> pas de compatibilité avec hook précédent
- suppression auto des tâches lors de la désinstallation d'un plugin (par le coeur)
- Faire en sorte que les plugins passent après les taches du core
Interface : objet standard
- liste des taches existantes
- colonne "anomalie" pour mise en évidence (code retour, date > 2 * freq, ...)
- formulaire
- onglet principal (+ statut + lancement manuel)
- onglet log
- en plus des données DB, afficher l'état en cours
Exécution
- ignorer/nettoyer les "lock" aberrants (date > 2 * freq)
- lecture des locks / recherche dans la DB (pas de lock, active, interne/externe, blacklist, last_exec + freq < maintenant)
- pose du lock
- execution + mise à jour log de la tache
- suppression du lock + mise à jour DB (stat)
Question :
Les paramètres actuellement dans la table glpi_config pourrait être transférés dans la table de config des tâches (et de nouveaux créés)
- log => délai de conservation
- mailgate => nombre de mail
- ocsng => nombre de machine / spécifique a chaque serveur attention ! -> rendre global
- etc
Bon du coup on aurait un champ générique dans la table (param ?) pas très explicite, mais ça me semble plus logique de trouver ça là pour l'utilisateur.
MoYo : met t'on en place une vérification pour un cron qui ne passe jamais car l'utilisateur à fait une mauvaise config ? Code couleur sur les dernier passage des crons ?
goals¶
- manage internal/external task
- enable/disable task
- manage plugin task
proposed implementation¶
- a new table which handle each task configuration
- we keep file lock (which allow lock from external process, p.e. backup script)
- a new tab in configuration form
For each task :
- core/plugin, name, description
- frequency (can change by user)
- mode : disable, manual, internal, external
- backlist hour (p.e. don't optimize between 7 and 18, don't get mail between 17 and 8 : only during support hours)
- enhanced cron.php
A new parameter to choice which task will be done : priority (actual implementation for internal), all (mainly for external), name (to force one task)
- log method
Propose the cron status for each task in the application.
Question : do we use a DB or file log ?
MoYo : today : launch / success information in DB / detail information in file log.
- plugin
Must be compatible with old plugin hook.
Offer a register/unregister function for plugin task (to be called during plugin (un)installation).
Walid : add informations about cron execution in nagios status.php page