Erreur Tar: EOF inattendu dans l'archive lors de l'exécution via Cron / PHP
j'ai un script de console PHP qui s'appelle via cron et qui crée entre autres un fichier tar d'un répertoire.
lors de l'appel du script PHP via cron, le fichier tar n'est pas créé correctement. L'erreur suivante est donnée lors de la visualisation du fichier tar:
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
en appelant manuellement le script PHP via la console, le fichier tar est créé correctement. La sortie du journal cron ne montre aucune erreur.
Voici l'appel tar du PHP script.
exec("cd $this->backupTempFolderName/$id; tar -czf ../../$this->backupFolderName/$tarFileName $dbDumpFileName documents");
Dose quelqu'un a une idée de pourquoi le goudron est correctement créé manuellement appelé et échoue lorsqu'il est appelé par cron?
mise à Jour: L'erreur donnée lors de la création du fichier tar via cron est:
tar: ../../backup/20150819-060003.tar.gz: Wrote only 4096 of 10240 bytes
tar: Error is not recoverable: exiting now
Parfois, l'erreur est:
tar: ../../backup/20150819-054002.tar.gz: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now
comme dit plus haut, le fichier tar est créé lorsqu'il est exécuté via cron, mais toujours 50% de la taille correcte (lors de l'exécution manuelle du le script):
-rw-r--r-- 1 gtz gtz 1596099468 Aug 19 06:25 20150819-042330.tar.gz <- Manually called skript, working tar
-rw-r--r-- 1 gtz gtz 858570752 Aug 19 07:21 20150819-052002.tar.gz <- Script called via cron, broken tar
mise à Jour 2
après avoir fait quelques recherches supplémentaires basées sur les entrées données ici, might devrait ajouter que le cron appelé script tourne sur un serveur privé virtuel - je soupçonne que certaines limites peuvent exister pour les tâches cron qui ne sont pas documentées par l'hébergeur (seule limite sur le temps minimum de répétition est donnée dans les docs).
8 réponses
cette erreur vient généralement du manque d'espace disque.
je voudrais faire un peu plus de recherches sur ce sujet, en ajoutant quelques logs avant et après l'exécution de tar.
vérifiez également l'utilisateur que votre configuration utilise pour la tâche cron que vous avez exécutant la sauvegarde. Il peut y avoir une limite de quota sur cet utilisateur aussi, cela n'arrive pas lorsque vous exécutez sur la console en dehors de cron.
demandez à votre fournisseur des quotas sur le VPS pour les utilisateurs et pour les processus... C'est ce que sonne la cloche ici.
je suppose que vous avez une limitation des ressources Comme M. Ivanov l'a dit, Ajoutez cette commande dans votre script PHP:
shell_exec("php -info");
et vérifiez ce paramètre à la fois lorsque vous exécutez votre script depuis la ligne de commande et depuis la commande cron
memory_limit => ???
vous pouvez également essayer d'exécuter votre cron en augmentant la limite de mémoire à 1600M
php -d memory_limit=1600M scriptCompressor.php
Espérons que cela aide :)
vous pouvez essayer de créer le tarball directement à partir de PHP pour éviter le exec appel. Voir la réponse:https://stackoverflow.com/a/20062628/5260945.
Aussi, en regardant votre entrée cron, il n'y a pas de slash sur votre exemple. Je sais que cela pourrait juste être une faute de frappe pour le commentaire, mais assurez-vous que vous avez un chemin absolu pour le cd la commande. L'environnement par défaut pour une tâche cron n'est pas le même que pour votre shell de connexion.
cronjobs par eux-mêmes n'ont généralement pas de limites. Si vous utilisez un hébergement partagé, ils ont peut-être installé des scripts d'exécution, mais je pense qu'ils casseront aussi les sauvegardes de votre console.
si vous utilisez cronjobs à partir d'un conteneur, par exemple Drupal, ils ont des limites spéciales.
vérifiez aussi les limites de bash avec:
ulimit -a
signalez l'espace disque avant le début de la sauvegarde et après juste au cas où. Il est généralement assez petit sur VPS.
je suis sûr de sa mémoire ou de temps d'exécution du problème. Faites une chose lancez le même script pour le répertoire qui ne contient qu'un seul fichier de test et vérifiez la sortie, si votre script fonctionne dans ce scénario puis 100% sûr de son problème de mémoire.
essayez de modifier le paramètre mémoire et d'exécuter votre script.
j'espère que cela vous aidera.
Merci
l'erreur.
tar: ../../backup/20150819-054002.tar.gz: Cannot write: Broken pipe
tar: Error is not recoverable: exiting now
je vois que la fonction exec dans le script PHP ne bloque pas ou ne cause pas d'erreur prématurément. Donc la session PHP qui reçoit est appelée pendant la fin du travail Cron avant la fin de la commande. C'est juste une supposition, mais vous pouvez essayer de l'envoyer à l'arrière-plan lorsque vous l'exécutez à partir de Cron.
exec("cd $this->backupTempFolderName/$id; tar -czf ../../$this->backupFolderName/$tarFileName $dbDumpFileName documents &");
cette commande devrait être bloquée donc c'est juste un tir dans le noir.
erreur se produit lorsque vous essayez d'exécuter le fichier php et donne L'erreur EOF. Cela signifie que quelque part dans votre fichier php vous devez vérifier le code de votre fichier cron il peut arriver que vous oubliez de compléter les parenthèses de l'état ou de la classe etc...
Bonne chance ['}
Pour consigner les erreurs dans le journal lorsqu'il est exécuté par cron remplacer >/paht/to/application/app/logs/backup-output.log dans le cron ligne par 2>&1 >/path/to/application/app/logs/backup-output.log
Vérifiez également le chemin dans la ligne cron .. peut-être que le change-dir ne fonctionne pas comme vous pourriez le penser. Essayez d'imprimer getcwd() à un log ou quelque chose, quand on exécute le script php à partir de cron.
Edit: je me demande pourquoi cela a été voté à l' not useful. L'interlocuteur mentionné qu'aucune erreur n'est imprimé dans le journal lorsque le cron exécute le script. Ce n'est pas difficile d'imaginer que > juste redirige le STDOUT et non le STDERR (sur lequel les erreurs php seraient imprimées) vers le journal. Ainsi, l'ajout de 2>&1 pourrait révéler de nouvelles informations.