Comment faire pour exécuter un script bash via Cron

J'ai vu d'autres questions similaires, mais je ne trouve pas de réelles informations sur la façon de trouver le bon moyen d'exécuter un script Bash via Crontab. Le .sh fichier se trouve dans le répertoire de l'utilisateur (dans mon cas serverpilot).

Le script essaie de copier le contenu de la apps dossier et de l'envoyer à mon S3 seau. Le script fonctionne parfaitement lorsqu'il est exécuté avec sh backupS3.sh à partir du terminal, mais pas de joie via Cron. J'ai vu des personnes de référence des variables de CHEMIN d'accès et, mais aucune idée où commencer!

/backupS3.sh

#!/bin/sh
echo 'Started backing to S3'
date +'%a %b %e %H:%M:%S %Z %Y'
aws s3 sync /apps s3://bucketname
date +'%a %b %e %H:%M:%S %Z %Y'
echo 'Finished backing to S3'

crontab

*/10 * * * * /backupS3.sh >> backupS3.log

Quelqu'un peut-il m'indiquer à quoi que ce soit évident que je fais mal? Merci!

EDIT: j'ai ajouté 2>,&1 à la fin de la commande cron et maintenant j'obtiens quelque chose dans le fichier journal:

/bin/sh: 1: /backupS3.sh: not found

  • Vous dites que ça ne marche pas, mais ce qui se passe réellement?
  • Désolé @JordonPhillips le script n'est pas en cours d'exécution je crois que la synchronisation n'arrive jamais, et l'écho des déclarations ne sont pas imprimés dans le journal
  • Je tiens à souligner qu'il est création du fichier journal, mais que le fichier reste vide
  • Votre script est un sh script, mais de l'exécuter avec bash est inoffensif. Le contraire n'est généralement pas. De toute façon, vous devez comprendre la différence avant qu'il saute et vous pique. Voir, par exemple, stackoverflow.com/questions/5725296/...
  • Aussi, ce n'est pas vraiment une question de programmation; serverfault serait un meilleur choix dans l'avenir.
  • Quel est le chemin d'accès complet à backupS3.sh?
  • Les points sont pris @MarkReed, si c'est possible pour qu'il soit déplacé, ce serait super, si non la prochaine fois, je vais jeter un oeil là-bas. Merci.
  • Basé sur les commentaires ci-dessous, c'est /srv/users/serverpilot/backupS3.sh

InformationsquelleAutor André Goldstein | 2016-06-01
  1. 7

    Dans les chemins, le premier / ne veut pas dire "home directory"; il se réfère toujours à la racine du système de fichiers, peu importe qui vous êtes connecté en tant qu'. Vous devez utiliser le plein, de chemin absolu du script (par exemple,/home/serverpilot/backupS3.sh). Si la crontab appartient à la même utilisateur dont la maison répertoire contient le script, vous pouvez utiliser "$HOME"/backupS3.sh et le système de remplissage dans leur maison chemin de répertoire pour vous. Ou, encore plus simplement, il suffit d'utiliser ./backupS3.sh, depuis cron jobs commencer avec leur répertoire de travail égale à leur propriétaire le répertoire home de l'.

    Si cela ne fonctionne pas, alors soit ce que tu veux dire par "répertoire de l'utilisateur" n'est pas la même que la POSIX concept de "home directory", ou le script n'est pas exécutable (que vous pouvez corriger en exécutant la commande chmod +x backupS3.sh une fois).

    Si vous n'êtes pas sûr de ce que le chemin d'accès complet est, il suffit d'exécuter le pwd de commande pendant que vous êtes dans le répertoire qui contient le script, et de mettre la sortie, suivi d'une barre oblique, en face du nom du script.

    • Merci, où dois-je exécuter que chmod commande? Comme un one-off dans le terminal?
    • Oui, il a juste à être exécuté une seule fois.
    • Merci beaucoup. D'ailleurs le aws s3 sync /apps s3://bucketname ligne dans le script lui-même, qui savent où regarder ou va qui doivent constituer l'intégralité du chemin d'accès au serveur aussi? Merci encore.
    • Si le répertoire est /apps, grand. Si c'est apps sous le répertoire home de l'utilisateur, puis qui doit aussi être "$HOME"/apps.
    • Lorsque Cron exécute un travail, il commence dans votre maison driectory. Peut-être tout ce que vous avez besoin est ./backupS3.sh
    • Merci beaucoup @MarkReed, je suis maintenant à la réception de la suite dans mon journal de /srv/users/serverpilot/backupS3.sh: 4: /srv/users/serverpilot/backupS3.sh: aws: not found ne sais Pas si c'est encore en disant qu'il ne peut pas trouver le script ou c'est un problème avec l'aide de l'AWS CLI?
    • Le aws de commande n'est pas dans le cron job $PATH. Vous aurez besoin de spécifier le chemin d'accès complet ainsi (que vous pouvez obtenir avec which aws).
    • Génial, merci beaucoup de la Marque.
    • Merci @tripleee je pense que je n'ai essayer qu'initialement.
    • Évidemment /srv/serverpilot n'est pas l'invocation répertoire home de l'utilisateur; mais cette réponse de tri d'suppose que le script existe dans votre répertoire home, dans lequel cas, la réponse pourrait être plus simple.
    • Je soupçonne que c'est plus que la tentative avec la ./ chemin était avant la chmod.
    • Cette réponse est très utile et m'a aidé à obtenir le script en cours d'exécution. Je suis maintenant en cours d'exécution dans une AWS informations d'identification de l'erreur, mais je pense que c'est dû à la configuration de l'AWS à l'origine en tant qu'utilisateur root
    • Maintenant, fonctionne parfaitement. Merci à tous pour votre superbe de l'aide.

    InformationsquelleAutor Mark Reed
  2. 5

    D'abord, changer #!/bin/sh à #!/bin/bash, à côté d'utiliser le chemin complet du script (également .sh n'est pas nécessaire dans le nom de fichier)

    */10 * * * * /home/users/me/backupS3.sh >> /home/users/me/backupS3.log
    • Je vous remercie. Quand vous dites d'utiliser le nom de chemin complet, je ne suis pas sûr de l'endroit où le point de cette situation? J'ai ajouté la Crontab de l' serverpilot utilisateur (j'ai aussi accès à la racine du serveur, mais pensé qu'il était préférable de vous connecter en tant serverpilot). Je connais plein chemin d'accès au serveur à elle, dois-je l'utiliser?
    • Le bash indice est un leurre; votre script actuellement ne contient pas de Bash spécifiques des constructions.
    • Merci pour l'info @triplee
    • red herring? C'est complémentaire et constructive, car l'utilisateur est l'affichage de ce comme un "bash question" Pas besoin d'un vote, comme le chemin était la question.
    • Les conseils pour modifier l'arborescence n'est pas correct; il n'a tout simplement pas aider à résoudre le problème.
    • puis par votre logique, après vous donner les conseils (utiliser le chemin d'accès complet), toute aide supplémentaire est incorrect. J'ai peur que cela va à l'encontre de tous les principaux de l'aider. Peut-être le problème est que vous avez arrêté la lecture de la réponse quand vous avez obtenu à la partie que vous n'aimez pas.
    • En fait, j'ai lu l'intégralité de la réponse, et il serait bien si vous avez retiré la partie qui est incorrect. Il existe de nombreuses situations où les conseils aurait de l'aide, mais ce n'est pas l'un d'eux. Recommander de toute façon, elle ressemble à culte du cargo de programmation pour moi, ce qui je pense est basé sur un mauvais principes (d'ailleurs, pas de "principes").

    InformationsquelleAutor SaintHax
  3. 1

    J'ai eu le même problème où le fichier journal a été créé à vide, et la seule façon de voir ce qui se passait, c'était d'ajouter 2>&1 à la fin de la tâche cron.

    */10 * * * * /home/users/me/backupS3.sh >> /home/users/me/backupS3.log 2>&1

    Si quelqu'un se demande ce 2>&1 signifie réellement ici est une courte explication:

    2 - se réfère à un descripteur de fichier utilisé pour identifier stderr

    1 - se réfère à un descripteur de fichier utilisé pour identifier stdout

    Donc 2>&1 fondamentalement se traduit par: Rediriger stderràstdout

    InformationsquelleAutor foobar