Merci Denis d'avoir le temps de lire et de répondre à ce mail indigeste :-)
Pour répondre à tes questions, nous avons une tache planifiée qui s'exécute à tous les démarrages du poste et qui fait appel à un .bat dont le contenu est le suivant:
timeout /t 300 /nobreak \educ-for.local\sysvol\educ-for.local\wapt\waptdeploy.exe --hash=8ff39e48[...]2bce90d9338 --minversion=1.7.4.6232 --wait=15 --waptsetupurl=https://wapt%5B...%5D.educationetformation.fr/wapt/waptagent.exe --setupargs=/dnsdomain=educationetformation.fr --setupargs=/wapt_server= --setupargs=/repo_url= --setupargs=/hiberboot_enabled=0 --setupargs=/pre_shutdown_timeout=180 --setupargs=/max_gpo_script_wait=180
Cette tache planifiée qui s'exécute à chaque démarrage nous produit l'erreur "waptdeploy is already runing... exit" vu que la tache fullwaptupgrade s'exécute avant sans jamais rendre la main...
La grande question est : pourquoi le waptupgrade s'exécutant au démarrage du poste plante sans donner signe de vie, en laissant derrière lui un process waptagent.tmp (0% cpu et et à peine qq 100ene de ko d'utilisation de la RAM) J'avais tenté à l'époque de debugger ce problème avec Hubert sans succès.
Il faudrait voir pourquoi il y a des tâches planifié sont restées en arrière-plan, elles sont normalement supprimées à la fin du paquet tis-waptupgrade
Je n'ai pas trouvé dans le code de suppression de tache planifiée. Et cela m'intéresse car j'ai bien vu dans le XML du schtasks une entrée DeleteExpiredTaskAfter à PT0S sauf que la doc Microsoft spécifie: "A task expires after the end boundary has been exceeded for all triggers associated with the task. The end boundary for a trigger is specified by the EndBoundary property inherited by all trigger objects."
Le EndBoundary est fixé à +90j à la création de la tache il me semble, donc d'après ce que je comprends.
Bonne soirée
-----Message d'origine----- De : Denis Cardon dcardon@tranquil.it Envoyé : lundi 25 novembre 2019 17:57 À : MORILLO Jordi j.morillo@educationetformation.fr; wapt@lists.tranquil.it Objet : Re: [Wapt] Debug mise à jour waptagent
Bonsoir Jordi,
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 :
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
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é J
J'ai frôlé la rupture d'anévrisme, mais c'est passé quand même... :-)
Il faudrait voir pourquoi il y a des tâches planifié sont restées en arrière plan, elles sont normalement supprimées à la fin du paquet tis-waptupgrade. En effet on est obligé d'utiliser une tâche planifiée sinon on a un soucis de la poule et de l'oeuf avec le paquet WAPT qui va essayer de se modifier lui même (Les locks exclusifs Windows, c'est bien et casse pieds à la fois).
On pourrait cependant vérifier au démarrage du service si il n'y a pas des restes et les nettoyer.
Par rapport aux questions sur les API, je pense que les deux éléments à voir: * l'historique (il y a probablement du refactoring à faire) * le support de WinXP (il en reste encore beaucoup dans l'industrie et dans les trucs du genre appliances).
Est ce que ce problème est reproductible? Est ce que tu lances l'installation de l'agent à travers une GPO au démarrage, à l'extinction ou par tâche planifiée? Si tu nettoies une machine qui a le problème (suppression des tâches résiduelles), est ce que ces tâches planifiées reviennent toutes seules?
à bientôt,
Denis
Bonne soirée !
WAPT mailing list WAPT@lists.tranquil.it http://lists.tranquil.it/listinfo/wapt
-- Denis Cardon Tranquil IT 12 avenue Jules Verne (Bat. A) 44230 Saint Sébastien sur Loire (FRANCE) tel : +33 (0) 240 975 755 http://www.tranquil.it
Tranquil IT recrute! https://www.tranquil.it/nous-rejoindre/ Samba install wiki for Frenchies : https://dev.tranquil.it WAPT, software deployment made easy : https://wapt.fr