Discussion :

[gadj0dil0]

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).

[jlliagre]

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.

[srvremi]

Au minimum je teste mes scripts CRON en supprimant le PATH user.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#!/bin/bash
 
export PATH=""
 
.......

@+
Rémi

[jlliagre]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
PATH=/bin:/usr/bin
...

PS: pas besoin d'exporter la variable PATH, elle l'est déjà, toujours.

[gadj0dil0]

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

[jlliagre]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

PATH=$PATH:/opt/phpmachin/bin:/var/phptruc/bin

PS: Dans les forums, pas besoin de se vouvoyer.

[gadj0dil0]

Ce n'est pas une bonne pratique de mettre le path complet pour chaque occurrence de ces commandes.

Juste pour crontab

Merci quad même pour toutes ces précisions.

[srvremi]

Salut.

Pour le PATH en multi-distribution, j'ai deux cas possibles (avec un template Puppet par exemple) :

1. Je récupère la valeur de $PATH du $USER au moment de la création du script.
2. Je fais des which sur les commandes concernées au moment de la création du script.

@+
Rémi

[jlliagre]

Juste pour crontab

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.

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.

[gadj0dil0]

Salut.

1. Je fais des which sur les commandes concernées au moment de la création du script.

t1 j'ai lu la définition de WICH dans le man je n'ai rien compris!
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.

[gadj0dil0]

Exemple
-----------

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
who -b
         system boot  2017-10-25 12:18
 
crontab -l
* * * * * LANG=fr_FR.UTF-8 who -b > test
* * * * * who -b >> test
 
cat test
         system boot  2017-10-25 12:18
         system boot  Oct 25 12:18

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é !

[jlliagre]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
LANG=fr_FR.UTF-8
...
* * * * * who -b > test
* * * * * autre commande et ses options >> test

[gadj0dil0]

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.

[jlliagre]

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.

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.

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.

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.