History

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