Bonjour a tous
Je viens vers vous parce que là, je suis a cours d'idées…
Sur un serveur (CentOS) j'ai un script de sauvegarde qui se lance toute les nuits, qui me fait 4 dump et 2 tar.
Sauf que :
Mes dump se font sans problème (ouf)
Mes tar en revanche… Ils sont vides. Le script se lance, les fichiers sont créés, je n'ai pas de log d'erreur, mais ils sont vides.
Le plus surprenant, c'est que si je lance le script à la mano, tout fonctionne correctement.
Autre point d'incrédulité, le format de la date change…
Si le script est lancé par le cron, il ressemble à ça : (mon fichier de cette nuit)
-rw-r--r-- 1 root root 5544 avr 19 00:30 html-19-Apr-2019.tar.gz
Avec le mois en anglais et en maj.
Par contre à la main ça donne ça :
-rw-r--r-- 1 root root 55383776 avr 19 12:32 html-19-avr-2019.tar.gz
Avec le mois en français et en minuscule…
Je suis perdue. Si quelqu'un à une idée..
Pour info, la ligne de mon script ressemble à ça :
tar zvcf html-$date.tar.gz --exclude=fichiers-a-exclude fichiers-à-save 2>> $log_sql_dest
Merci d'avance pour toute idée !
Tisla
# Les pièges du cron
Posté par gUI (Mastodon) . Évalué à 8.
Le pb du cron c'est qu'il n'est pas exécuté dans le même contexte que à la main dans ton shell.
Déjà, quel utilisateur exécute la commande ? Souvent c'est root, donc exécute ton script en root pour voir comment il se comporte.
Ensuite les variables d'environnement sont souvent vides, le .bashrc n'ayant pas été exécuté (d'où peut-être le changement de langue).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Les pièges du cron
Posté par JJD . Évalué à 3.
Concernant la langue utilisée,je peux confirmer que dans l'environnement de cron, la langue n'est pas positionnée (variable LANG) et que c'est donc l'anglais (en pratique "C"), qui est utilisée.
Pour éviter cela, on peut positionner la variable dans le script (export LANG=fr_FR.UTF-8) si cela est nécessaire mais, à mon avis, il est préférable de mettre la date sous un format de type AAAAMMJJ (ce qui permet en plus le classement des fichiers produits).
Sur la question du fichier tar vide, il faudrait un peu plus de détails. La commande tar, telle que tu l'as fournie, archive les fichiers fichiers-à-save du répertoire courant. Est-ce que tu as pensé à faire préalablement un cd pour te placer dans le bon répertoire ? (peut-être que lorsque tu exécutes le script manuellement, tu t'étais bien placé dans le bon répertoire pour voir le résultat…)
Tu expliques aussi que ton fichier de log est vide mais que contient-il si tu rediriges aussi la sortie standard et pas seulement la sortie d'erreur ?
[^] # Re: Les pièges du cron
Posté par Tisla . Évalué à 1.
Pour la langue ça a pas d'importance, c'est juste que je trouvais ça bizarre que ça change entre le lancement à la main et le lancement via cron.
Pour l'emplacement, il y a effectivement un cd dossier juste avant, je l'avais pas copié. et le script je le lance a la main en root, mais le cron est en root aussi…
J'ai lancé le script en cron et j'ai aucune erreur, juste la liste des fichiers…
Mais.. C'est démoniaque ! Mon tar est bon !!!!
Et j'ai rien changé!!! quelle est cette magie ???
# Je pige plus là...
Posté par Tisla . Évalué à 1.
Alors si je résume : si dans mon script j'ai une redirection d'erreur ou pas de redirection en sortie de tar ça marche pas.
Mais avec une redirection générale ça marche ??? C'est logique ça???
J'ai retenté chaque possibilité et je confirme, avec 2>> ou rien marche pas. avec >> ça marche…
Une idée du pourquoi quelqu'un? Help? XD
[^] # Re: Je pige plus là...
Posté par JJD . Évalué à 1.
C'est intéressant comme comportement…
Je me suis dit que cela pouvait être lié à l'absence de sendmail sur ton système. Les sorties d'erreur et standard d'une tâche cron, si elle ne sont pas redirigées, sont envoyées par mail au propriétaire du cron.
Est-ce qu'il est possible que, ce mécanisme ne fonctionnant pas, le script se plante ? De mon côté, je n'ai pas réussi à reproduire le souci (sous Debian)
Une première piste est de regarder si des choses s'affichent dans les logs système quand tu ne rediriges pas la sortie standard (fichiers syslog, message, cron dans /var/log/ ou journalctl suivant que tu utilises systemd ou pas).
[^] # Re: Je pige plus là...
Posté par Tisla . Évalué à 1.
Le sendmail est pas configuré… mais avant mes changement, la sortie redirigeait les erreurs vers un fichier de log des sauvegarde.
Le script se déroulait en entier, puisque mes dump se font après le premier tar, et ils se font sans problème.
Je vais aller fouiller les log… Avec tout ce que j'ai lancé aujourd'hui je dois avoir de la matière…
[^] # Re: Je pige plus là...
Posté par Kerro . Évalué à 1.
En principe non. S'il n'y a pas Sendmail ou équivalent, il y a juste une entrée dans les logs.
# Quelques nouvelles
Posté par Tisla . Évalué à 1.
Je reviens vous tenir au courant après ce week end pascal.
Du coup suite à cette découverte de la magie du Démon, j'ai créer 2 fichiers de log (un pour chaque tar) pour récupérer les données en sortie de tar, histoire de pas surcharger mes log de save.
Et tout fonctionne bien. Mon tar HTML en local, mes dump n'ont pas bougés, et mon tar global pour envoyer le tout sur le NAS.
J'ai toujours pas compris pourquoi bash (si c'est lui qui merdoie) refuse tout autre redirection de sortie, mais au moins ça marche !
Merci de votre aide en tout cas, parce que sans la suggestion de JJD je serai encore en train de m'arracher les cheveux!
Si jamais je découvre d'où ça vient, je vous tiendrai au courant.
@+ Tisla
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.