Bonjour à tous,
Je travaille sur un projet contenant une Beaglebone black sous Debian Jessie.
Je suis en train de faire un script exécuté par Udev lors de l'insertion d'une carte µSD. (mon but à terme est de rediriger les logs sur la carte µSD à son insertion et de remettre les logs sur la mémoire interne au retrait.)
la partie déjà écrite de ce script (la création d'un dossier vierge pour pouvoir y monter la carte) fonctionne très bien lorsqu'exécutée à la main… mais impossible d'en tirer quoi que ce soit lorsqu'il est exécuté par Udev.
Voici le script en question:
#!/bin/bash -xe
#
#Author: Jerome LEKIEFFRE
#This script has been written for ARO Welding Technologies only
#
#This script creates the /media/sdcard folder in order to mount the sdcard in it
#Error codes:
# - 2 : /media/sdcard already exist but is not a directory
# - 1 : Failed to create /media/sdcard/
logger -t SDCardscripts 'Entering /root/ServolineScripts/PrepareSDCard.sh script'
if [ -d /media/sdcard ]; then
logger '/media/sdcard is already present. Deleting it.' && rm -rf /media/sdcard;
elif [ -f /media/sdcard ]; then
logger -t SDCardscripts 'A file /media/sdcard already exist! Stopping process, Please look in the /media directory and take a decision with it content'
exit 2
else
logger -t SDCardscripts '/media/sdcard does not exist creating a new one'
fi
mkdir -p /media/sdcard
if [ $? -eq 0 ];then
logger -t SDCardscripts '/media/sdcard directory successfully created';
else
logger -t SDCardscripts 'Failed to create /media/sdcard directory'
exit 1;
fi
logger -t SDCardscripts 'Leaving /root/ServolineScripts/PrepareSDCard.sh script'Lorsque j'exécute le script à la main, il fonctionne à merveille, quelle que soit la condition (avec un dossier déjà présent, avec un fichier du même nom,…)
Mais quand Udev doit le faire, voici ce que j'obtiens en logs:
Nov 27 13:53:49 undefined kernel: [ 903.988337] mmc0: card 0007 removed
Nov 27 13:53:50 undefined kernel: [ 904.645474] mmc0: host does not support reading read-only switch, assuming write-enable
Nov 27 13:53:50 undefined kernel: [ 904.648883] mmc0: new high speed SDHC card at address 0007
Nov 27 13:53:50 undefined kernel: [ 904.658300] mmcblk0: mmc0:0007 SD08G 7.42 GiB
Nov 27 13:53:50 undefined kernel: [ 904.660093] mmcblk0: p1
Nov 27 13:53:50 undefined SDCardscripts: Entering /root/ServolineScripts/PrepareSDCard.sh script
Nov 27 13:53:50 undefined SDCardscripts: /media/sdcard does not exist creating a new one
Nov 27 13:53:50 undefined systemd-udevd[1951]: Process '/root/ServolineScripts/PrepareSDCard.sh' failed with exit code 1.
Donc pour résumer, mon script arrive à créer le dossier (et donc je suis ensuite capable de monter la carte µSD) quand je l'exécute à la main, mais il semble planter à la création du dossier lorsque Udev le lance…
J'ai posé la question sur d'autres forums mais j'avoue n'avoir trouvé aucune réponse à ce jour à ce problème étrange. Cela fais près de deux semaines que je m'arrache les cheveux là dessus…
On m'as déjà demandé pourquoi avoir un rm puis un mkdir, c'est parce que le système peut interagir avec la carte µSD automatiquement, sans se demander si elle es présente ou non, il créé un dossier /media/sdcard dans lequel il écris des fichiers… et je le fais aussi parce que la Beagle se trouve dans une armoire électrique sous très haute tension. il est donc inconcevable d'enlever la carte µSD à chaud, et l'armoire ne s’arrête que lorsqu'on coupe le courant à l'entrée… donc la Beagle n’exécute jamais de phase d’extinction (donc ne démonte jamais la carte µSD…)
Si vous êtes un mordu de Udev, ou non, mais dans tous les cas si vous avez une idée… même débile… Je suis persuadé que l'erreur se situe entre le siège et le clavier mais je ne trouve rien…
# Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . Évalué à 2.
Salut,
Si tu enlèves ta carte, le système peut vouloir logguer l’événement avant de le passer à μdev, du coup l’écriture de l’arrachement de la carte plante puisque le loggue ne peut s’écrire ?
Autre solution :
J’aurais, fait différemment, et je ne maîtrise pas très bien μdev.
Tu loggue dans un fichier sur le disque. Quand tu insères la carte, tu copies le fichier et tu mets un inotify sur le fichier de loggue.
À chaque changement du fichier log sur le disque dur, si la carte est présente, tu copies le loggue sur la carte.
Quand il y a arrachement, tu enlèves l’inotify.
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
Je prend bonne note de ta proposition. Mais à l'heure actuelle, la fonctionnalité de déplacement des logs n'est même pas encore implantée. Le problème est que je ne peut même pas monter la carte car le système n'arrive pas à créer le dossier /media/sdcard dans lequel je souhaite monter la carte… (je vais modifier un peu mon post car je vois que je n'ai pas été très clair sur ma question :) )
Je ne connaît pas inotify, aurait-tu un bon lien l'expliquant? (la compréhension de l'anglais n'est pas un problème donc si tu as un lien en anglais cela me convient parfaitement) sinon je vais faire mes recherches moi même :)
Merci pour l'idée!
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . Évalué à 3.
Si c’est à l’insertion de la carte. Le script dans μdev est peut-être exécuté avant le montage du système de fichier.
Quel événement filtres-tu dans μdev pour exécuter ton script ?
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
j'exécute à l'insertion:
ACTION=="add", SYMLINK+="disk/by-label/sdcard", RUN+="/root/ServolineScripts/PrepareSDCard.sh"(si c'est bien ce que tu me demande…)
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . Évalué à 3.
Donc ton script est exécuté avant que le système de fichier ne soit activé sur la SD. Il faut attendre le
mount.Lis ça.
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
Ben surtout qu'a l'heure actuelle je ne lui demande pas de monter la carte puisqu'impossible de créer le dossier dans lequel je souhaiterais qu'il me la monte…
Si je comprend bien ce qui est dit dans les liens que tu m'as mis, Systemd est capable de détecter la présence de la carte (on laisse les règles par défaut Udev la monter là où il le souhaite alors?) et on exécute le script à partir de là? L'idée me plaît, cela seras probablement plus stable de laisser Udev faire comme il le souhaite et d’interagir avec le produit finis (si je puis dire) directement.
Ce que je voit c'est qu’apparemment il est écris quelque part à propos d'Udev qu'il ne supporte pas les gros scripts… Il semblerait que je n'ai pas suffisamment RTFM… :)
Mais du coup cela veut dire que je n'ai plus la main sur le dossier dans lequel le système monte la carte… peut-être, ceci dit, qu'il est plus stable d'utiliser des liens plutôt que de se mettre directement dans la carte…
J'aimais bien l'idée d'avoir quelque chose de fixe. Et surtout simple de configuration pour les autres personnes présentes dans le projet…
Ce que j'aurais aimé faire c'est une règle qui ne fasse qu'appeler mon script qui lui ferais le reste…
(initialisation des dossiers et montage de la carte puis après les modifications sur les logs)
et un service Systemd ou cron qui, à chaque démarrage, réinitialise le système (on part du principe que la carte n'est pas présente, et si par hasard elle est présente on agis…) donc qui supprimerais toutes traces de la carte et reconfigurerais les logs (en gros mon idée pour les logs c'etait : Stopper rsyslog, déplacer les logs, supprimer /var/log, créer un lien de /var/log vers /media/sdcard/log, redémarrer rsyslog. Et donc au retrait de la carte suppression du lien et création du dossier /var/log… mais c'est un premier jet qui pose des soucis…)
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . Évalué à 3.
Disons que le temps que tu passes dans ton script met la suite des étapes pour ce périphérique en attente.
Sinon, j’avais pas bien compris ce que tu voulais faire… je me suis orienté sur des race conditions mais ça ne doit pas être ça.
Une autre idée débile, les droits du répertoire /media ? es-tu certain que le script exécuté par μdev à les droits d’écritures ?
Il est possible que le script soit exécuté avec un utilisateur udev qui ne soit pas root. (je dis peut-être une connerie) je peux pas vérifier au boulot.
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
J'ai bien vérifié, /media est libre en écriture et lecture pour tout le monde normalement.
A priori Udev est sensé exécuter les scripts en root puisqu'il est lui même exécuté en root…
J'avais commencé par mettre un sudo mais rien n'y fais…
Je ne connaissait pas ce terme de race condition mais si je récapitule mon idée c'est que ce script serve à initier la carte µSD en créant un dossier propre pour qu'ensuite Udev puisse monter la carte dedans donc cela me conviens bien que Udev soit en pause le temps que le dossier soit créé…
Enfin je crois…
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . Évalué à 3.
Race condition : un problème de concurrence dépendant de l’ordonnancement. Quand tu as plusieurs fils/thread dans un programme, ils ne s’exécutent jamais exactement dans le même ordre temporel. Ce qui provoque souvent des bugs aléatoires et difficile a déboguer.
J’ai utilisé le terme pour dire que le problème pouvait peut-être provenir d’un problème temporel dans le sens où en fonction du timing d’exécution du script par rapport à la création du device, montage… tu puisses être dans des conditions différentes entre ton test manuel et automatique.
Je continue à réfléchir, un truc qui m’étonne, c’est que on a l’impression que c’est le mkdir qui sort sans rendre la main à ton script, dans ta retranscription des log, il devrait y avoir une ligne avec
'Failed to create /media/sdcard directory'or dans le log, ce n’est pas le cas.Je réfléchie tout haut.
Est-ce qu’il n’y aurait pas des restrictions d’appel système dans un événement μdev ?
Peux-tu lister les appels système de
mkdiravec strace ?Je ne sais pas quoi dire, je suis un peu perdu. Peux-tu confirmer si c’est le mkdir qui plante et que tu ne passes jamais dans le
ifsuivant, ou si c’est un manque du log ?[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1. Dernière modification le 28 novembre 2017 à 17:17.
Cela effectivement ne se voyait pas dans les logs car mon code commence par
#!/bin/bash -xe(le '-e' arrête mon script à la première erreur rencontrée. Mais si j'enlève ce fameux 'e', je vois bien le résultat de mon test suivant, donc mkdir me rend la main mais termine avec un code différent de 0.
(après l'avoir imprimé je peut même te dire qu'il se termine en renvoyant la valeur 1)
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . Évalué à 3.
Ok, donc
mkdirretourne 1. Unman mkdirsur mon linux RHEL6 ne donne rien d’utile, par contreman 2 mkdirdonne les codes d’erreur de l’appel système en C.Si tu remplaces la ligne du mkdir par :
strace mkdir -p /media/sdcard 2>/tmp/log_strace.txtensuite, tu cherches le résultat de mkdir dans log_trace.txt.Je n’ai pas d’autre idée pour l’instant.
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
il n'écris rien dans le fichier… il n'en créé même pas…
C'est à n'en rien comprendre… mkdir n'as pas de résultat…
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par NeoX . Évalué à 3.
et si tu regardais comment font les gestionnaires de fichiers,
car finalement c'est deja eux qui font le dossier et le montage dans /media/xxx/maclef
tu dois pouvoir t'inspirer de ce qui fait pour faire la meme chose, non ?
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
Pas bête mais c'est souvent assez tordu à comprendre parce que beaucoup plus généraliste que ce que je souhaite faire…
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par NeoX . Évalué à 3.
pour l'instant ton probleme semble quand meme bien "generaliste"
et ta remarque m'etonnes, car pour moi c'est hyper generaliste que de monter une clef USB dans un dossier particulier
ensuite que tu veuilles modifier la destination des logs quand le clef est presente ou non, c'est un autre detail,
et là, inotify ou udev peuvent te permettre de jouer un script à la detection de la clef qui change la destination des logs (modification d'une config ®syslog et relancement de celui-ci)
mais laisse faire le truc de base (le montage) aux outils prevus pour, ou regardes comment ils font, tu eviteras de reinventer la poudre et te concentrera sur la modification de la destination des logs
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
C'est effectivement probablement le plus sage, mais je me disait que ce serais peut-être moins une usine à gaz si tout était dans un seul et unique script… Du coup quuelqu'un saurait s'il vaut mieux faire éxecuter un script à Udev ou directement des commandes les unes après les autres (par exemple pour déplacer les logs…)
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par NeoX . Évalué à 2.
ca depend de ce que tu veux,
j'ai cru comprendre que tu veux logguer par defaut sur la machine, et sur la carte SD quand elle est branchée
j'en deduis que c'est pour sortir les logs de la machine quand tu fais des tests, sans perdre les logs habituels,
je dirais donc qu'il vaut mieux ne rien changer sur les logs, et quand la clef est branchée, juste copier les logs courants,
puis ejecter la clef quand tu as finis
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
Oui c'est mon idée mais la question était plutôt, vaut-il mieux écrire un script et demander à Udev de l'exécuter ou écrire le script dans la règle Udev? (ce serais beaucoup plus propre dans un fichier pour le script mais au niveau fonctionnel?)
(en posant la question je pense connaître la réponse mais… autant profiter du sujet pour avoir l'avis d'autres…)
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
Si je veux utiliser inotify, je vois comment faire pour un fichier en particulier mais est-il possible de faire un inotify sur un dossier qui copierait le fichier qui as été modifié de ce dossier ailleurs?
(un genre de:
A=0while $A = 0
do
if [!carteSDmonté];then A=1;
fi
inotifywait -q -q -o /media/sdcard/inotify.log -e modify /var/log/*
cp /var/log/"le_fichier_modifié" /media/sdcard/"le_fichier_modifié"
done
)
je sais pas trop si je suis bien clair ^
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
[^] # Re: Log après arrachement et avant rechangement ?
Posté par JeromeLEKIEFFRE . Évalué à 1.
(je devrais peut-être faire un nouveau sujet pour ça…)
Bien souvent, si tu as un problème, demande toi qui est le couillon qui viens d'écrire le script que tu viens d'écrire... ça y est, il y a de fortes chances pour que tu ai trouvé le coupable! Et si en l'intérogeant tu ne trouve rien, vas faire dodo!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.