You are not logged in.
Bonjour a tous
J'ai un plugin qui se desactive systematiquement après le lancement d'une tache automatique (sccm)
Aucune erreur ou autre niveau php, qui pourrait m'indiquer ce qui peut déclencher ce disable svp ?
Merci
Offline
Bonjour
Ca pourrait être intéressant de savoir quel plugin se trouve désactivé.
La tâche de sccm est la seule à provoquer le souci ?
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Il s'agit du plugin sccm (la tache automatique est créée par ce plugin)
Elle semble pourtant se dérouler sans problème particulier, mais le plugin est désactivé peu de temps après l'activation
Offline
Donc c'est sccm qui se désactive tout seul à l'exécution de sa propre tâche ?
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Tres bonne question, en fait j'active le plugin, je lance la tache (tout semble bien se passer), et je retrouve le plugin disabled peu de temps après (aucune idée du pourquoi du comment)
Offline
(Hors sujet)
Last edited by spamma.master (2018-03-27 09:43:53)
Offline
A priori le plugin se désactive tout seul après quelques minutes (surement une tache automatique qui provoque cela, mais pas la tache sccm)
Cela pour effet de désacativer le schedule de la tache, donc ennuyeux
Aucune chose à vérifier pour trouver ce qui provoque cette désactivation ?
Last edited by spamma.master (2018-03-27 09:44:41)
Offline
If anyone has a good idea on this subject, I would take it because even a forced crontab will not launch the task (because the plugin is disabled I guess):
I tried this but cron says nothing to do: /var/www/default/html/glpi/front/cron.php --force sccm
Offline
Hi
I encountered such issue years ago with Fusion Inventory, without finding the cause. I guess this would be a good idea to patch GLPI in a way it logs a date/time and a backtrace when it disables a plugin, until you catch these data. This may give a good clue to understand which event causes this issue.
Do you have a pre production environment on which you're able to reproduce the bug and introduce such patch ?
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
I dont have a pre production environment but I can apply the patch anyway if it is understandable
I have no clue yet on what is doing that (on this plugin only...)
Offline
I don't know if someone already did such patch. It is not so hard to create it, but to avoid any risk on a production instance, it is necessary to validate it on an other instance.
Do you have ability to create an other installation of GLPI (separate host) which is exactly the same as your current instance ? By the way, this is good practic to keep it. You may safely test upgrades and any risky tasks (life saver habit).
Last edited by btry (2018-03-28 10:41:08)
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Dont worry, if it is an error_log to put in someplace to add some debug info, it has been already done as this server can take a little downtime
Offline
I think it would be better to use Toolbox::logDebug() or Toolbox::logInFile(). The 2nd is better because you can put a text, to be used when searching in the log.
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
I have already used that to debug this sccm plugin, so no problem at all, if you can just tell me where to look to "hook" where plugin are disabled
Offline
In inc/plugin.class.php you will find a constant NOTACTIVATED. Searching in the whole GLPI source code for this constant, you should find all places where a plugin may be deactivated. Place a call to Toolbox::logInFile() in every appropriate place. Check by disabling a plugin that you actally get a log entry. Be careful about any typo !
Finally wait until the plugin disables itself, and read the log again. The backtrace should give you a very useful information.
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline
Perhaps more in function unactivate($ID)
Will do that first thing in afternoon
I will put Toolbox::logInFile('sccmdebug', "Passed here\n", true), but I dont see how I will get more informations, that will just tell me that the code has been triggered ? not the backtrace to check what called the procedure ?
Last edited by spamma.master (2018-03-28 14:04:26)
Offline
Pour suivi sur ce problème, j'ai réussi à trouver qu'effectivement cette partie de code est appelée:
$function = "plugin_".$plug."_check_config";
if (function_exists($function))
{
if (!$function())
{
Toolbox::logInFile('sccmdebug', "Passed here\n", true);
$usage_ok = false;
}
}
Il me reste à trouver pourquoi cela passe ici
Offline
J'ai pu trouver pourquoi le plugin se désactive
En fait, le plugin fonctionnait via l'interface graphique mais pas via l'appel cron (CLI)
L'appel cron utilisait une version CLI de php où il manquait les modules nécessaires pour le plugin, et donc il se désactivait tout seul car plugin_sccm_check_config n'était pas satisfait
L'ajout des modules dans la config PHP CLI a résolu le problème complètement
Offline
Bien !
Ca vaudrait peut être le coup de mettre des entrées de log côté GLPI quand un plugin se fait désactiver.
No support with MP - Always run an upgrade task on a testing instance before running it on production! Always backup before any upgrade task!
Offline