Comment tester des choses dans crontab

Cela continue de m’arriver tout le temps: 1) J’écris un script (ruby, shell, etc.). 2) lancez-le, ça marche. 3) mettez-le dans crontab afin qu’il fonctionne dans quelques minutes, donc je sais qu’il fonctionne à partir de là. 4) Il n’y a pas de trace d’erreur, retour à l’étape 2 ou 3 1000 fois.

Lorsque je script ruby ​​échoue dans crontab, je ne peux pas vraiment savoir pourquoi il échoue, car lorsque je diffuse comme ceci:

ruby script.rb >& /path/to/output 

Je reçois en quelque sorte la sortie du script, mais je ne reçois aucune des erreurs et je ne reçois pas les erreurs provenant de bash (comme si ruby ​​est introuvable ou si le fichier n’y est pas)

Je ne sais pas quelles variables environnementales sont définies et si cela pose problème. Il s’avère que pour exécuter un script ruby ​​à partir de crontab, vous devez exporter une tonne de variables d’environnement.

Existe-t-il un moyen pour que crontab lance un script comme si je le diffusais moi-même depuis mon terminal ?

Lors du débogage, je dois réinitialiser la timer et revenir à l’attente. Très long

Comment mieux tester les choses en crontab ou éviter ces problèmes?

“Est-ce que je peux faire en sorte que crontab lance un script comme si je le faisais moi-même depuis mon terminal?”

Oui:

 bash -li -c /path/to/script 

De la page de manuel:

 [vindaloo:pgl]:~/p/test $ man bash | grep -A2 -m1 -- -i -i If the -i option is present, the shell is interactive. -l Make bash act as if it had been invoked as a login shell (see INVOCATION below). 

G’day,

L’un des problèmes de base de cron est que cron définit un environnement minimal . En fait, vous avez seulement quatre env. var sont définies et elles sont:

  • SHELL – défini sur / bin / sh
  • LOGNAME – défini sur votre ID utilisateur, tel que trouvé dans / etc / passwd
  • HOME – défini sur votre répertoire personnel. comme trouvé dans / etc / passwd
  • PATH – défini sur “/ usr / bin: / bin”

C’est tout.

Cependant, vous pouvez prendre un instantané de l’environnement souhaité et l’enregistrer dans un fichier.

Maintenant, faites de votre source cronjob un script shell sortingvial qui génère cet env. fichier, puis exécute votre script Ruby.

BTW Avoir une source de wrapper un env commun. Le fichier est un excellent moyen d’imposer un environnement cohérent pour plusieurs tâches cronjobs. Cela renforce également le principe DRY, car il ne vous donne qu’un point pour mettre à jour les choses au besoin, au lieu de chercher dans un tas de scripts et de rechercher une chaîne spécifique si, par exemple, étant utilisé, par exemple le gnutar au lieu du goudron de vanille.

En fait, cette technique est utilisée avec beaucoup de succès avec The Build Monkey, qui est utilisé pour implémenter l’continuous integration pour un projet logiciel majeur commun à plusieurs grandes compagnies aériennes mondiales. 3 500 kSLOC sont vérifiés et construits plusieurs fois par jour et plus de 8 000 tests de régression sont effectués une fois par jour.

HTH

‘Avahappy,

Exécutez une commande ‘set’ depuis l’intérieur du script ruby, lancez-la depuis crontab et vous verrez exactement ce qui est défini et ce qui ne l’est pas.

Pour connaître l’environnement dans lequel cron exécute les travaux, ajoutez ce travail cron:

 { echo "\nenv\n" && env|sort ; echo "\nset\n" && set; } | /usr/bin/mailx -s 'my env' [email protected] 

Ou envoyez la sortie à un fichier au lieu de l’email.

Vous pouvez écrire un script wrapper, appelé par exemple rbcron , qui ressemble à rbcron :

 #!/bin/bash RUBY=ruby export VAR1=foo export VAR2=bar export VAR3=baz $RUBY "$*" 2>&1 

Cela redirecta l’erreur standard de Ruby vers la sortie standard. Ensuite, vous lancez rbcron dans votre travail cron, et la sortie standard contient out + err de ruby, mais aussi les erreurs “bash” de rbcron lui-même. Dans votre entrée cron, redirigez 2>&1 > /path/to/output pour obtenir les messages d’erreur en sortie + pour aller à / path / to / output.

Si vous voulez vraiment l’exécuter vousmême , vous pouvez invoquer ruby ​​à partir d’un script shell qui .profile votre .profile / .bashrc etc. De cette façon, il va attirer votre environnement.

Cependant, l’inconvénient est qu’il n’est pas isolé de votre environnement, et si vous changez cela, vous pouvez constater que vos tâches cron cessent soudainement de fonctionner.