Version imprimable
Bonjour a tous,
J'ai un petit soucis avec le crontab.
J'ai une ligne sur deux qui s'execute.
Crontab :J'ai ajouté la deuxieme ligne mais elle ne s'execute pas a l'heure voulu, pourtant la Premiere ligne continu de bien s'executer.Code:
2
3
Comment ca se fait?
Merci d'avance à ceux qui m'aideront
Bonjour,
A tout hasard, as-tu pensé à recharger cron ? :
++Code:/etc/init.d/cron reload
Fred
quelques unes des distractions qui peuvent mener à ce comportement :Citation:
Envoyé par nicohand94
a. oublier de rendre le script exécutable
b. erreur de shebang
c. mauvaises fins de lignes (CR au lieu de LF)
d. typo dans le path
e. un dossier du path n'est pas accessible par l'utilisateur qui exécute le cron
…
Alors j'ai essayé de recharger le cron mais ca ne marche toujours pas.
Pour moi la commande étaitPour ce qui est du script je l'ai bien rendu executable : chmod 755Code:/etc/init.d/crond reload
Et pour le PATH je ne pense pas que c'est ca car il utilise les memes commandes que la premiere ligne.
Par contre qu'est-ce que c'est que l'erreur de shebang?
Le script est bon car quand je lance manuellement le .sh il fait bien l'export.
Je ne comprends pas pourquoi le cron ne lance qu'un script sur les deux....
Bonjour,
Si le service crond a éte redémarré, c'est le script qui ne fonctionne pas. C'est le cron de quel user? Pour tester le script, il faut être ce user dans le home-dir sans avoir lancé aucune commande auparavant.
le shebang c'est la première ligne du script indiquant le programme qui doit interpréter la suite…Citation:
Envoyé par nicohand94
#!/bin/sh … par exemple
et si il y a une typo sur cette ligne …
Bonjour,
Est-ce que ton script est ecrit pour etre executable sans environnement ?
Si oui, il devrait fonctionner dans le cas suivant (a faire a la main) :
Une fois fini, tapes ctrl + d pour revenir dans ton shell initial.Code:
2
3
4
ça m'etonne que ça vienne du script parce que c'est exactement le même que le premier mis a part que le repertoire de backup est différent c'est tout.Citation:
Envoyé par jmelyn
Et que quand je lance le script manuellement il fonctionne très bien.
Je navigue dans le serveur en root mais c'est l'utilisateur oracle qui lance ces script. J'ai pris le soin de fairepour ajouter les lignes pour lancer le script.Code:crontab -u oracle -e
gangsoleil pour ce que tu m'a dit, quand je tappe bash ça ne fait rien... ca reste dans le shell normal...
Je viens de refaire la vérif Ce matin et le script de la deuxieme ligne ne s'est toujours pas lancé...
Je vous met mon script et mon crontab de l'user oracle voir si vous voyez quelquechos qui cloche...
export1.sh :crontab :Code:
2
3
4
5
6
7
8
Code:
2
3
montrez donc la sortie de
Code:
2
3
4
Il n'y a qu'une seule manière de déboguer un cron qui ne marche pas. Il faut rediriger les messages d'erreur éventuels (stderr) vers un fichier ou un terminal actif.
Le terminal actif est donné par la commande tty. Dans la plupart des cas il s'agit d'un chemin incomplet ou relatif dans une ligne du script. On parie?Code:
2
3
4
5
Merci pour ces réponses,
alors pour la sortie des commandes SeirtEmgie ca donne :
C'est a priori logique vu que le PATH est vidé je pense.Code:
2
3
4
5
6
7
8
9
10
11
Pour les commandes de ripat, le script ne fonctionne toujours pas.
Ce que je trouve étrange c'est que les deux script sont presques identiques et pourtant un fonctionne et l'autre non
EDIT :
Je viens de voir ca dans le log :
Code:
2
3
4
5
6
7
8
9
Bonjour,
Quelles sont les differences entre tes scripts ?
Pourquoi ne pas commencer par corriger ton script en y ajoutant le chemin absolu des commandes, puis le relancer en environnement vierge (comme JeitEmgie ou moi te le demandions), puis continuer a corriger tant qu'il y a des erreurs ?
Mes commandes ne changent rien au script. Elles ne font que rediriger les erreurs vers un fichier. As-tu été voir ce que le fichier /tmp/err_cron contient?Citation:
Envoyé par nicohand94
Faire de la ligne de commande sans retour d'erreur est du pilotage sans visibilité.