Version imprimable
Bonjour,
Y a t-il un moyen de lancer les tâches du crontab en test (sans modifier les horodatages). Sachant que crontab a son propre environnement (il ne connaît pas celui des users me semble t-il,les locales, les chemins des binaires...) il est bien parfois de tester (sans passer par un copié-collé dans le shell).
Pour tester un crontab, il n'y a pas d'autre méthode de test fiable.
Le plus simple est de dupliquer la ligne à tester et de planifier une exécution quelques minutes plus tard, puis de supprimer la ligne après.
Au minimum je teste mes scripts CRON en supprimant le PATH user.
@+Code:
2
3
4
5
Rémi
Heu... c'est un peu extrême comme approche, non ?
Ça t'oblige a mettre le chemin complet pour toutes les commandes (non builtin) utilisées, même les commandes standard alors qu'avec cron, ce n'aurait pas été le cas.
Ce qu'on peut suggérer plutôt, c'est :
PS: pas besoin d'exporter la variable PATH, elle l'est déjà, toujours.Code:
2
Merci de votre réponse, pour ma pat dans le crontab je met les chemins complets des binaires, je ne me pose même plus la question surtout avec tous les chemins de php par exemple, et en fonction des différents hébergeurs... PHP n'est pas built-in (core-utils) ok, mais la "base" dépend aussi des distributions. Il y a vraiment 1000 manières de faire les choses :
Merci pour vos réponses
1/ Les built-ins, c'est les commandes internes au shell (ex: cd, echo, read), pas core-utils. Il n'y a pas besoin de PATH pour les exécuter.
2/ Tous les systèmes Unix et Unix like disposent d'un certain nombre de commandes standard (définies par POSIX, comme cat, ls, awk, sed, rm, mv, etc. et dont quelques unes sont fournies par core-util sous GNU). Ces commandes doivent obligatoirement être accessibles avec le PATH par défaut. Sous Linux, ces commandes sont soit dans /bin, soit dans /usr/bin (soit les deux).
Ce n'est pas une bonne pratique de mettre le path complet pour chaque occurrence de ces commandes. Par exemple, des commandes comme yes, cut ou expr vont se trouver dans /usr/bin sur certains Unix-like et dans /bin dans d'autres. Il faudra que tu fasses une version de script par système cible, ce qui est absurde.
Pour ne pas avoir ce problème, il suffit de ne pas retirer ces deux répertoires du PATH (et de les laisser en début de PATH) pour qu'elles continuent à être utilisables. Si tu veux gérer le cas où les commandes non standard que tu utilises peuvent se trouver dans des endroits différents suivant les distributions, il suffit d'ajouter la liste des tous les chemins possibles dans ton PATH dans le script appelant :
Code:PATH=$PATH:/opt/phpmachin/bin:/var/phptruc/bin
PS: Dans les forums, pas besoin de se vouvoyer.
Juste pour crontab :roll:Citation:
Envoyé par jlliagre
Merci quad même pour toutes ces précisions.
Salut.
Pour le PATH en multi-distribution, j'ai deux cas possibles (avec un template Puppet par exemple) :
- Je récupère la valeur de $PATH du $USER au moment de la création du script.
- Je fais des which sur les commandes concernées au moment de la création du script.
@+
Rémi
Ah, désolé, j'avais mal compris. Je pensais que tu parlais des scripts appelés par la crontab, pas des commandes spécifiées dans la crontab.Citation:
Envoyé par gadj0dil0
Dans ce dernier cas, tu peux bien sûr mettre le chemin complet vers les commandes appelées, ou simplement redéfinir le PATH au début du fichier crontab.
t1 j'ai lu la définition de WICH dans le man je n'ai rien compris!Citation:
Envoyé par srvremi
which retourne le chemin des fichiers qui seraient exécutés dans l'environnement courant si ses arguments avaient été donnés comme commandes dans un interpré‐
teur de commandes strictement conforme à POSIX. Pour ce faire, which cherche dans la variable PATH les fichiers exécutables correspondants aux noms des argu‐
ments. which ne déréférence pas les liens symboliques.
Ok ca affiche le PATH du fichier.
Je précise que je ne met les chemins que dans le crontab (pas les scripts appelés)
Comme dit jlliagre "redéfinir le PATH au début du fichier crontab" me semble pas mal et je testerais.
Exemple
-----------
J'ai dans mon crontab un script appelé, je ne renseigne pas la varibale LANG dans le crontab : pour avoir mon formatage je suis obligé de la mettre dans le fichier appelé !Code:
2
3
4
5
6
7
8
9
10
11
Ton crontab appelle un binaire, pas un script. Il n'est pas (raisonnablement) possible de modifier un binaire pour forcer une variable d'environnement. Tu peux utiliser un script qui appelle le binaire et faire les modifs dans ce script que tu appelleras avec la crontab.
Il y a plus simple, tu peux mettre les affectations de variable que tu souhaites au début du fichier crontab. Elles impacteront toutes les entrées de la crontab:
Code:
2
3
4
Merci pour l'info si ca affecte toutes les tâches. Juste une précision, effectivement j'appelle un binaire dans le crontab pour l'exemple, mais à la base j'appelle un script qui lance le binaire who. Les scripts sont souvent écrits avec des binaires (sed, grep, awk, cut,rev...). Je pensais qu'en exécutant un script le binaire serait exécuté dans l'environnement du propriétaire du script. Pourquoi ne pas exécuter le tout dans l'environnement du propriétaire de la tâche, à priori c'est plus dans l'environnement du "propriétaire" du binaire.
Les binaires (comme les scripts) sont exécutés dans l'environnement qu'ils héritent de leur processus parent. Ils peuvent (comme les scripts) modifier leur propre environnement.Citation:
Envoyé par gadj0dil0
Il n'y a pas "un" environnement du propriétaire de la tâche mais autant d'environnements que de programmes. L'environnement n'est pas partagé; cron ne sait pas quel environnement un utilisateur souhaite pour les tâches de la crontab donc préfère les exécuter dans un environnement minimal mais prévisible.Citation:
Pourquoi ne pas exécuter le tout dans l'environnement du propriétaire de la tâche, à priori c'est plus dans l'environnement du "propriétaire" du binaire.