PEBKAC #8445

J'administre un ordonnanceur sur un gros SI, et assure le support pour tout un tas de gens qui ne savent pas s'en servir correctement pour gérer leurs applications (ils ne sont pas formés).
Pour faire très simple, un ordonnanceur sert à automatiser l'exécution de commandes sur des machines distantes : à telle heure, si telle commande s'est terminée en succès sur telle machine, je lance telle autre commande sur telle autre machine.

Ce matin, je suis appelé par quelqu'un qui teste une nouvelle application parce que ses traitements, qui ne devraient durer que quelques minutes, sont en cours depuis plusieurs heures. Je vais voir le log des traitements en question (via clic droit sur la représentation graphique du traitement), qui se termine ainsi pour chaque traitement :

Pause
Press any key to continue . . .

Un peu pour le testeur qui n'est pas allé voir le log, et beaucoup plus pour le codeur qui a pondu un script interactif pour un ordonnanceur censé faire du 100% automatisé : PEBKAC.

PEBKAC #8445 proposé par Milyyym le 27/08/2013 | 18 commentaires | 👍🏽 👎🏽 +197

Pebkac pour le testeur c'est sûr, pour le codeur faudrait voir quel est le cahier des charges qui lui a été donné. Bon c'est sur il aurait pu détecter si le script était exécuté dans un environnement interactif et désactiver les demandes d'inputs si non.

Commentaire #108346 écrit par Bear'sBeard le 27/08/2013 à 09h14 | 👍🏽 👎🏽

Cela me rappelle Homer Simpson dans un épisode sur les gros travailleurs. Il ne trouvait pas la touche «Any Key». Il se trouvait fort désappointé.

Commentaire #108351 écrit par H. Finch le 27/08/2013 à 09h27 | 👍🏽 👎🏽

CHLP

Commentaire #108357 écrit par Picc le 27/08/2013 à 09h35 | 👍🏽 👎🏽

Question: est-ce possible que ça soit l'application lancée par l'ordonnanceur qui attend un retour? Comme on voit sur certaines applications en ligne de commande.
(ou alors j'ai peut-être pas du tout compris comment ça marche)

Commentaire #108367 écrit par Muphins le 27/08/2013 à 09h54 | 👍🏽 👎🏽

Une question me turlupine: L'ordonnanceur ne devrait-il pas avoir fermé l'entrée standard ?
Du coup, la lecture de la touche du processus aurait dû se terminer sur une erreur et non sur une attente infinie.

Commentaire #108368 écrit par but2ene le 27/08/2013 à 10h13 | 👍🏽 👎🏽

Pour ce client, ils ne font que du non interactif : tout doit être exécuté via l'ordonnanceur. Interdiction d'exécuter des commandes manuellement (même si en cas d'incident ils le font quand même).
Maintenant, c'est vrai que je n'ai pas le cahier des charges sous les yeux (client à prestataires multiples, je fais partie d'une autre boîte).

Commentaire #108369 écrit par Milyyym le 27/08/2013 à 10h17 | 👍🏽 👎🏽

Accessoirement, point que j'ai oublié tellement ça a l'air d'être peu utilisé, le codeur a son propre environnement de développement, censé être similaire à l'environnement de production (ce n'est malheureusement pas toujours le cas), sur lequel il doit valider le bon fonctionnement de ses scripts et de son plan d'ordonnancement avant de les livrer.

Note : j'ai mis codeur par simplicité, mais ce n'est pas une personne seule, et elle ne fait pas que du code. Il s'agit de tout un service (prestataire en général) qui pour une application donnée gère la conception selon les besoins du client, le codage, la création du plan d'ordonnancement, la définition de la supervision (sur différents outils), puis le support aux exploitants.

Commentaire #108375 écrit par Milyyym le 27/08/2013 à 10h44 | 👍🏽 👎🏽

Ben le gars à lancé un trainement, et l'ordonnanceur est censé lancer les tâches les unes après les autres automatiquement. Mais à chaque tâche, il demande à l'utilisateur d'appuyer sur une touche, sans lui afficher le message (puisque c'est dans les logs).
Je suis pas certain d'utiliser les bons termes...

Et si tu me réponds "c'est toi la tâche" je te transforme en cookie! >:)

Commentaire #108379 écrit par Moot le 27/08/2013 à 11h07 | 👍🏽 👎🏽

Réponse combinée à but2ene et Muphins qui a l'air de demander plus ou moins la même chose.

L'ordonnanceur est une sorte de gestionnaire de tâches (ou de cron pour les unixiens) évolué et déporté : en gros, tel jour à partir de telle heure, si telle commande s'est terminée de telle façon sur tel serveur, j'exécute telle autre commande sur tel autre serveur. Le but est d'automatiser l'exécution d'un grand nombre de scripts sur un nombre plus ou moins grand de serveurs (environ 75000 traitements sur 1000 machines pour la production dont je m'occupe).

Mais le machin a beau être plus évolué qu'un gestionnaire de tâches Windows ou un cron, il n'en est pas pour autant doué d'intelligence. Il est possible de paramétrer un kill après une certaine durée d'exécution (ou à une heure donnée), mais il faut que ce soit prévu dans le plan d'ordonnancement. L'ordonnanceur ne prendra aucune décision de lui-même.

Commentaire #108382 écrit par Milyyym le 27/08/2013 à 11h30 | 👍🏽 👎🏽

Il a peut-être aussi prévu une sortie écran. Mais comme les machines sont en datacenter et n'ont ni écran ni clavier (sauf exceptionnellement le temps d'une résolution d'incident système)...

Commentaire #108384 écrit par Milyyym le 27/08/2013 à 11h33 | 👍🏽 👎🏽

Heu tu n'as pas répondu à la question.

Mais bon pour l'instant tu ne décris pas grand-chose d'extraordinaire.

La question est pourquoi le processus lancé attend quelque chose sur l'entrée. Sachant qu'elle devrait être fermée.

Gestionnaire de tâches != planificateur de tâches

Commentaire #108386 écrit par but2ene le 27/08/2013 à 11h42 | 👍🏽 👎🏽

JE SUIS TRES DESAPPOINTE !!

Commentaire #108396 écrit par mini le 27/08/2013 à 14h02 | 👍🏽 👎🏽

Et lui aussi avait finit pas automatiser son taf en employant un espace d'oiseau à bascule

Commentaire #108403 écrit par Quelqu'un le 27/08/2013 à 14h57 | 👍🏽 👎🏽

Oups, je voulais effectivement parler du planificateur de tâches et non du gestionnaire, qui n'a rien à voir.
Je me demande pourquoi je mélange aussi souvent les deux lorsque j'en parle...

Commentaire #108409 écrit par Milyyym le 27/08/2013 à 16h28 | 👍🏽 👎🏽

Quant à savoir pourquoi, en présence d'un script interactif, l'ordonnanceur ne le met pas directement KO au lieu d'attendre une action manuelle ou un kill planifié, il n'est tout simplement pas prévu pour.
D'après le troubleshooting officiel, "[...] can submit only background processes.". Il est ensuite précisé qu'il peut exécuter des scripts interactifs, mais à condition de pouvoir interagir avec (donc une sortie écran, un écran et un clavier sur la machine, et quelqu'un devant).

Commentaire #108410 écrit par Milyyym le 27/08/2013 à 16h37 | 👍🏽 👎🏽

@but2ene : L'accès à stdin, c'est plus une question de setup de l'environnement d'exécution que de paramétrage de l'ordonnanceur, non ?

Enfin, s'il existe des arguments interceptés par le shell du style $ truc -ab --env-no-stdin, ça m'intéresse.

Commentaire #108422 écrit par Geist le 27/08/2013 à 17h39 | 👍🏽 👎🏽

Sous linux il y a le fichier vide qui est vachement utile. $ truc < /dev/null
Il va se prendre un EOF à chaque lecture.

L'équivalent sous Windows c'est truc < NUL .
Vous pouvez essayer avec pause < NUL. Normalement il n'attend plus rien.

Commentaire #108448 écrit par but2ene le 28/08/2013 à 09h16 | 👍🏽 👎🏽

Ben il suffit de rediriger l'entré standard vers null lors de l'exécution ça t'évitera ce genre de blague.
Normalement, ça devrait être fait quand il n'y a pas d'entrée standard.

Par contre en cas de question ça risque de tourner en boucle.
Une solution serait peut-être un pipe de yes.
Sous Linux il s'écrit $ yes, sous windows ça n'existe pas. Il faut arrêter d'écrire quand la sortie est fermée.
Je sais le faire en C mais en batch j'avoue avoir du mal car le simple

@echo off
 debut: echo y
 goto debut

yes.bat | pause renvois le message d'erreur : "Le processus a essayé d'écrire sur un canal inexistant" en boucle.
Par contre sous Linux while true; do echo y; done | read po Fonctionne au poil.

Mais bon il doit y avoir une commande à la con surement non documentée ;)

Commentaire #108449 écrit par but2ene le 28/08/2013 à 09h53 | 👍🏽 👎🏽