Bonjour à tous !!
Ayant quelques minutes, je décide de jeter un oeil au problème récurrent que nous rencontrons : Nous avons de très (trop) nombreux ordinateurs qui n'apparaissent pas « UP » dans la console mais pourtant qui mettent bien à jour l'heure de dernière connexion (d'ailleurs en écriant ce mot « connexion », je me rend compte qu'en français il est écrit « Dernière connection » dans la console).
Bref, j'ai édité via NSSM sur quelques-uns de ces ordinateurs le service « waptservice » afin qu'il s'exécute avec un -ldebug Après reproduction du problème et analyse du fichier log, rien de bien probant, le service se lance bien au démarrage du poste, fait ce qu'il doit faire, mais coupe peu de temps après son démarrage sans aucune information dans le fichier de log.
En faisant un rapprochement entre l'heure de coupure du service et l'eventlog, on se rend compte que le service wapt est arrêté par le planificateur d'évènement avec une certaine tache nommée « fullwaptupgrade ».... A partir d'ici, nous avons 2 cas de figure :
1) Problématique du « create_onetime_task »
La tache planifiée crée par le « create_onetime_task » du package waptupgrade s'exécute immédiatement au démarrage du poste... sauf que l'on se retrouve avec une vieille problématique non résolue d'un installeur qui n'aboutit jamais : Sur certains de ces postes, on retrouve après démarrage le process waptagent.tmp, sans activité... qui ne fait rien... (et notre antivirus Bitdefender n'est pas en cause ;-) Si on tue le processus waptagent.tmp et que l'on relance la tâche à la main, tout se déroule correctement. Il ne faut donc pas que cette tache démarre trop car dans ce cas elle ne se termine jamais et surtout elle se re-execute à chaque redémarrage du poste ; coupant ainsi que le waptservice après quelques secondes
ð Pour cette problématique, je vous propose d'intercaler un petit <Delay>PT5M</Delay> dans la section <BootTrigger> aux alentours de la ligne 163 du fichier https://github.com/tranquilit/WAPT/blob/master/waptupgrade/setup.py Cela exécutera la commande 5min après le démarrage du poste et non immédiatement
2) Problématique du « full_waptagent_install »
Comme je le disais au-dessus, on a donc certains postes pour lesquels il subsiste une tache planifiée « fullwaptupgrade » Si le package waptupgrade est mis à jour durant l'extinction du poste, et donc avec waptexit, le setup.py lance alors print run('schtasks /Create /RU SYSTEM /SC ONSTART /TN fullwaptupgrade /TR "%s" /F /V1 /Z' % cmd)...
ð Avec cette création de tache en mode V1 XP, on a revient à une tache qui s'exécutera au démarrage du poste sans aucun délais de 5min ce qui n'est pas vraiment souhaitable dans notre cas.
Du coup, en analysant le code de la section full_waptagent_install, plein de questions me viennent :
ð Ligne 252 : Pourquoi passer par une tache V1, c'est-à-dire compatibilité XP, si on sait d'avance qu'il n'est pas possible de mettre l'option /Z ? Pourquoi ne pas appeler directement create_onetime_task qui lui crée bien une tache plus « évoluée » ?
ð Ligne 228 : Si on passe at_startup=True, et que je lis bien le code, du coup il ne se passerait rien. A quoi donc sert cette variable ?
ð Ligne 283 : update_registry_version(package_wapt_version) ! Du coup, nos postes indiquent tous 1.7.4.6232 dans les programmes installés alors qu'en réalité ils sont en en 1.7.4.6165 ou 6229 avec une tache fullwaptupgrade résiduelle
J'espère ne pas vous avoir trop embrouillé :) Bonne soirée !