Salut,
En programmation il est important de bien séparer les données de leur affichage.
Effectivement, stocké les temps en seconde est une bonne idée. Ensuite il suffit de convertir le temps pour avoir un affichage joli.
83s => 1:23
4000s => 1h06:40
Il te faut également une fonction qui à partir d’une entrée te donne le temps en seconde.
1h02:00 => 3720
Pour les centièmes, il y a deux solutions :
Considérer les valeurs comme des valeur à virgule et donc 83.48s => 1mn 23s et 48 centièmes
Garder que des valeurs entières : au lieu de stocker 83, tu stockes 8300.
Avec le apt list j’ai pu vérifier que le driver nvidia était bien sur la version standard. Il ne compilait plus dû à un changement d’interface dans un .h au passage du 4.13 -> 4.14.
En passant le driver en backport tout roule.
Quand on dit que l’ordonnanceur est préemptif, ça veut dire qu’il peut interrompre une tâche s’il le veut… ou la laisser tourner s’il le veut.
C’est en opposition à l’ordonnanceur coopératif, ou il faut appeler une fonction spéciale pour être reschedulé, ou certaines fonction de l’OS le font d’eux même.
L’ordonnanceur à beau être préemptif (capable de préempté la tâche) si tu lui dit explicitement de la laisser tourner, il va le faire. Temps qu’on utilise l’ordonnanceur en temps partagé, tous les thread auront à un moment du temps CPU. En mode Temps Réel, c’est différent. Ce n’est pas à utiliser à la légère. Par exemple, malgré un aspect temps réel sur l’affichage de page internet, et comme ce n’est pas critique, les navigateur web utilise les priorités standard. Ça suffit la plupart du temps, et quand ça suffit pas, ce n’est pas grave.
Imagine que firefox, utilise des threads temps réel pour rendre une page… et que celle-ci prennent du temps à cause de sa complexité, son javascript… tout ton système serait à la ramasse. C’est pour ça que ce n’est pas utilisé comme ça. C’est moins grave que ça lague un peu, plutôt que ça bloque le système.
Je ne sais pas ce que tu veux faire, tu ne précises rien. Mais réfléchie bien à si tu en as vraiment besoin… après, si c’est juste des TPs pour appréhender les concepts, alors continue, il n’y a rien de mieux que de ce prendre les pieds dans le tapis pour comprendre qu’il faut les lever ;-)
d'accord et un processus de priorité 10 et de politique d'ordonnancement SCHED_RR est autant prioritaire qu'un processus de priorité 10 et de politique d'ordonnancement SCHED_FIFO ou les politique d’ordonnancement SCHED_FIFO sont plus prioritaire que SCHED_RR ?
Là, tu me poses une colle. Je ne joue pas à ça. À une priorité donnée, je mets soit RR soit FIFO, mais pas les deux. Il faudrait regarder ce qui est marqué dans la norme POSIX. Mais il y a toujours un risque sur l’implémentation sur le système que tu utilises. Quand on passe les tâches en TR, c’est pour gagner en maîtrise, ce n’est pas pour ajouter de l’incertitude. Donc je ne le ferai pas.
Instinctivement, je dirai que FIFO 10 est plus prioritaire que RR 10, mais moins que RR11. Mais je n’ai jamais essayé de mixer.
Je cite (vu sur un site) :
"(…). N’étant
pas préemptible, ce processus s’exécute jusqu’à la fin sans libération du processeur"
Il parle de processus de même priorité. C’est pour alerter que les autres tâches n’auront pas de CPU (en multi cœur c’est faux), et que ça peut bloquer l’ordi. Je vois ça plus comme une mise en garde. Mais je t’accorde que c’est imprécis.
je retrouve souvent ca, et je bug la dessus car j'ai l'impression de comprendre que le noyau laisse le processus finir sa tache peu importe qu'il y ait des processus de plus grande priorité.
Non, la tâche sera bien interrompu par des tâches plus prioritaire.
si j'ai deux processus de meme priorité mais avec un processus tres court en temps processeur et l'autre tres lent, alors l'ordonnanceur lance le premier (FIFO) car le processus qui est tres court peut se retrouver en second dans la file READY.
Je ne sais pas ce que tu veux faire. Le temps réel est quelques chose de particulier. Si tu veux faire de l’applicatif « normal » n’utilise pas. L’objectif du temps réel est de garantir des temps de réponse, pas d’aller vite. Donc toute ton architecture se base sur des euristiques de temps de traitement de chaque tâche, et chaque tâche répond a un stimuli auquel on veut répondre.
Ex: J’ai une tâche qui surveille la monté d’eau dans un aquarium. Je connais le débit d’eau, la hauteur au dessus de mon capteur, donc je sais déterminer combien de temps il me reste quand le capteur me dit plein. On enlève un peu de temps, il y a potentiellement des remous ou que sais-je.
À partir de ta cascade d’événements, qui produisent des réponses pouvant être des stimuli d’autres tâches.
Ce qui est différent avec la politique d'ordonnanceur RR qui lui aurait partagé le temps du CPU. Donc le politique SCHED_FIFO peut rendre des systèmes instables car il peut lancer pendant des heures juste un processus (dans le cas ou on a qu'un seul coeur et un seul thread processeur)?
Normalement, quand tu mets une tâche en SCHED_FIFO, c’est qu’elle est suffisamment courte.
Je ne sais pas où tu as lu ça, mais je pense que l’idée et de dire que tant qu’aucune tâche de plus haute priorité n’est prête, la tâche ne sera pas interrompue. Même si elle passe 1h à s’exécuter.
Néanmoins, il n’y a aucun rapport entre préemptif (adj.) et SCHED_FIFO qui est une politique d’ordonnancement. C’est un peu comme dire : « La couleur de ce chat est angora. ».
Pour résumer, oui un ordonnanceur qui implémente la politique SCHED_FIFO est un ordonnanceur préemptif.
Fait attention aux sites que tu lis. Certains expliquent des trucs qu’ils croient avoir compris, ça nous arrive à tous, mais quand on publie il faut être plus rigoureux de façon à ne pas induire quelqu’un en erreur.
Sur ton message précédent, j’ai été volontairement flou sur certains points pour pas te noyer au premier message. Si tu as besoin de précision, n’hésite pas à répondre là où tu as besoin.
Tu as deux modes de gestions multi tâches.
Le mode Temps Réél, et le mode temps partagé. Par défaut, on lance les processus en mode temps partagé. Je vais expliquer à la pelleteuse (très grosse louche) le principe de fonctionnement et comment nice modifie ça.
Quand on lance un programme en temps partagé, le noyau lui alloue un quota de temps. Partons du postulat que le quota par défaut est 100ms. Deux programmes « Ready » vont donc partagé le processeur chacun ayant 100ms de quota à tour de rôle. nice va modifier se quota : nice -m 20 va donner un quota de 120ms pour le programme correspondant. Mais n’empêchera pas l’autre programme d’utiliser son quota qui est toujours de 100ms. Néanmoins, sans nice chacun va s’exécuter pendant 5s. Si on a un quota 120/100, on va avoir un résultat de 4,xs contre 5,y (1-0,x == 0,y).
Les processus en mode TR (temps réel) ne rendent jamais la main ! (enfin, sauf s’ils se mettent en attente avec select par exemple). En fonction des priorités, ça peut rendre un ordinateur de bureau inutilisable (interface graphique bloquée…)
L’ordonnanceur choisi la tâche TR ayant la priorité la plus élevée, et l’exécute. Quand elle a fini, ou qu’elle se met en attente d’un événement extérieur, l’ordonnanceur donne la main à la nouvelle tâche prête ayant la priorité TR la plus élevée. S’il n’y a plus de tâche TR, les tâches en mode partagée sont exécutées.
La concurrence entre les tâches TR, s’effectue suivant deux modes. FIFO ou RR. Prenons deux tâches TR de même priorité :
en mode FIFO, la première qui a la main, s’exécutera jusqu’à ce qu’elle est terminée, puis l’autre tâche sera exécuté. Si la première redevient prête, elle attendra que la seconde est finie.
en mode RR, les deux tâches vont travailler en temps partagé, mais seulement entre elles, puisque les autres tâches sont moins prioritaires.
Le sched RR (Round Robin) il donne du temps alternativement à tous les process ayant la même priorité. Ceux de priorité inférieur ne seront pas exécuté.
C’est Sched FIFO, qui attendra que la tâche soit terminé pour exécuter la suivante.
Si tu es sur un réseau local, tu dois pouvoir trouver les autres avec du broadcast ou du multicast. Ensuite, avec la réponse tu as des IP, tu récupères les pairs des uns pour devenir pair avec les nouveaux.
Dans mon industrie, c’est l’inverse on court après les certitudes…
On a besoin d’être sûr que la boucle principale s’exécute bien en moins de 10ms (proc pas véloce) tout le temps.
Pour moi, l’optimisation doit être mesurable : gain, temps de dev et de maintenance… car la soupe infâme, quand il y a un bug, c’est encore plus infâme.
Au niveau de l’approche que j’adopte :
- Quelles sont mes contraintes temporelles ?
- Quels sont les traitements qui risque de déborder ?
En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.
Ma question pour l’auteur, c’est : entre le moment d’obtention des données et la limite de mise en ligne acceptable, tu as combien de temps pour combien de donnée ?
À partir de là, tu peux voir si tu tiens ou non. S’il faut optimiser ou pas. Parce que souvent, c’est rigolo d’optimiser, mais on oublie souvent que ça a un coût non négligeable. Dans certains métier comme le tien c’est vital, dans d’autre non. Par contre, si la maintenance à long terme est vitale, il vaut mieux pas faire trop d’optimisation (micro optimisation locale), et privilégier les bons algo structure de donnée.
Ok, donc mkdir retourne 1. Un man mkdir sur mon linux RHEL6 ne donne rien d’utile, par contre man 2 mkdir donne 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.txt ensuite, tu cherches le résultat de mkdir dans log_trace.txt.
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 mkdir avec 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 if suivant, ou si c’est un manque du log ?
Ce que je voit c'est qu’apparemment il est écris quelque part à propos d'Udev qu'il ne supporte pas les gros scripts…
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.
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 ?
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.
Il y a un journal : application qui se comporte comme vim car les vimeux doivent quitter vim pour faire certaines actions sur l’ordi en gardant leur interface alors que les emaceux restent sous emacs…
-->[]
Pour être sérieux, j’adore le mode modal de vim que aucune appli, pas même le viper-mode n’égale. Néanmoins, je trouve emacs plus cohérent avec son elisp.
Salut,
Je viens d’utiliser le cadre « recherche » en haut à droite de la page. La requête : « Netflix » m’a renvoyé sur cette page dont le premier lien est ton post, et le second un post qui explique comment activé netflix et canalplay.
En fait, si tu regardes le premier lien de la dépêche, tu verras que c’est la traduction de cet article posté le 10 octobre 2017 soit il y a un peu plus d’un mois.
# awk
Posté par Anthony Jaguenaud . En réponse au message remplacement dans fichier. Évalué à 1.
Awk permet de traiter un fichier ligne par ligne en matchant des regex ou des valeurs de champs.
Un truc du genre devrait marcher à peu près.
# Séparation donnée affichage
Posté par Anthony Jaguenaud . En réponse au message chrono en seconde python pour DB sqlite. Évalué à 3.
Salut,
En programmation il est important de bien séparer les données de leur affichage.
Effectivement, stocké les temps en seconde est une bonne idée. Ensuite il suffit de convertir le temps pour avoir un affichage joli.
Il te faut également une fonction qui à partir d’une entrée te donne le temps en seconde.
Pour les centièmes, il y a deux solutions :
J’espère être clair…
# Merci
Posté par Anthony Jaguenaud . En réponse au message Revenir sur le choix d'un backport. Évalué à 2.
Merci à vous deux.
Avec le
apt list
j’ai pu vérifier que le driver nvidia était bien sur la version standard. Il ne compilait plus dû à un changement d’interface dans un.h
au passage du 4.13 -> 4.14.En passant le driver en backport tout roule.
# Je ne m’embête pas…
Posté par Anthony Jaguenaud . En réponse au message Ecrire des fichiers sur un CD en 2018 !. Évalué à 10.
J’utilise
k3b
le logiciel de KDE. Il fait le job en utilisant les outils en ligne de commande que tu as cité.Si tu as un « linux » moderne, insère un CD vierge dans ton lecteur et ton desktop devrait te proposer automatiquement un logiciel.
[^] # Re: "Le Logiciel Libre fait partie de notre ADN"
Posté par Anthony Jaguenaud . En réponse à la dépêche Cozy, votre domicile numérique. Évalué à 5. Dernière modification le 29 janvier 2018 à 12:47.
Et utiliser weboob pour la partie bancaire ?
Edit: Grillé… :'(
# Vraiment joli.
Posté par Anthony Jaguenaud . En réponse au journal Une CSS « froide » pour l'hiver : Steelblue. Évalué à 3.
Je trouve ça vraiment très beau. Je vais probablement remplacer ma CSS actuelle.
Il y a deux détails :
Comme je ne sais pas vraiment ce qu’on peu faire, je ne pense pas être pertinent pour proposer des améliorations, encore moins les réalisés.
[^] # Re: Définir non préemptif…
Posté par Anthony Jaguenaud . En réponse au message SCHED_FIFO et non préemptif c'est à dire. Évalué à 3.
Quand on dit que l’ordonnanceur est préemptif, ça veut dire qu’il peut interrompre une tâche s’il le veut… ou la laisser tourner s’il le veut.
C’est en opposition à l’ordonnanceur coopératif, ou il faut appeler une fonction spéciale pour être reschedulé, ou certaines fonction de l’OS le font d’eux même.
L’ordonnanceur à beau être préemptif (capable de préempté la tâche) si tu lui dit explicitement de la laisser tourner, il va le faire. Temps qu’on utilise l’ordonnanceur en temps partagé, tous les thread auront à un moment du temps CPU. En mode Temps Réel, c’est différent. Ce n’est pas à utiliser à la légère. Par exemple, malgré un aspect temps réel sur l’affichage de page internet, et comme ce n’est pas critique, les navigateur web utilise les priorités standard. Ça suffit la plupart du temps, et quand ça suffit pas, ce n’est pas grave.
Imagine que firefox, utilise des threads temps réel pour rendre une page… et que celle-ci prennent du temps à cause de sa complexité, son javascript… tout ton système serait à la ramasse. C’est pour ça que ce n’est pas utilisé comme ça. C’est moins grave que ça lague un peu, plutôt que ça bloque le système.
Je ne sais pas ce que tu veux faire, tu ne précises rien. Mais réfléchie bien à si tu en as vraiment besoin… après, si c’est juste des TPs pour appréhender les concepts, alors continue, il n’y a rien de mieux que de ce prendre les pieds dans le tapis pour comprendre qu’il faut les lever ;-)
[^] # Re: Définir non préemptif…
Posté par Anthony Jaguenaud . En réponse au message SCHED_FIFO et non préemptif c'est à dire. Évalué à 2.
Là, tu me poses une colle. Je ne joue pas à ça. À une priorité donnée, je mets soit RR soit FIFO, mais pas les deux. Il faudrait regarder ce qui est marqué dans la norme POSIX. Mais il y a toujours un risque sur l’implémentation sur le système que tu utilises. Quand on passe les tâches en TR, c’est pour gagner en maîtrise, ce n’est pas pour ajouter de l’incertitude. Donc je ne le ferai pas.
Instinctivement, je dirai que FIFO 10 est plus prioritaire que RR 10, mais moins que RR11. Mais je n’ai jamais essayé de mixer.
Il parle de processus de même priorité. C’est pour alerter que les autres tâches n’auront pas de CPU (en multi cœur c’est faux), et que ça peut bloquer l’ordi. Je vois ça plus comme une mise en garde. Mais je t’accorde que c’est imprécis.
Non, la tâche sera bien interrompu par des tâches plus prioritaire.
Je ne sais pas ce que tu veux faire. Le temps réel est quelques chose de particulier. Si tu veux faire de l’applicatif « normal » n’utilise pas. L’objectif du temps réel est de garantir des temps de réponse, pas d’aller vite. Donc toute ton architecture se base sur des euristiques de temps de traitement de chaque tâche, et chaque tâche répond a un stimuli auquel on veut répondre.
Ex: J’ai une tâche qui surveille la monté d’eau dans un aquarium. Je connais le débit d’eau, la hauteur au dessus de mon capteur, donc je sais déterminer combien de temps il me reste quand le capteur me dit plein. On enlève un peu de temps, il y a potentiellement des remous ou que sais-je.
À partir de ta cascade d’événements, qui produisent des réponses pouvant être des stimuli d’autres tâches.
Normalement, quand tu mets une tâche en SCHED_FIFO, c’est qu’elle est suffisamment courte.
# Définir non préemptif…
Posté par Anthony Jaguenaud . En réponse au message SCHED_FIFO et non préemptif c'est à dire. Évalué à 5. Dernière modification le 19 janvier 2018 à 12:23.
Je ne sais pas où tu as lu ça, mais je pense que l’idée et de dire que tant qu’aucune tâche de plus haute priorité n’est prête, la tâche ne sera pas interrompue. Même si elle passe 1h à s’exécuter.
Néanmoins, il n’y a aucun rapport entre préemptif (adj.) et SCHED_FIFO qui est une politique d’ordonnancement. C’est un peu comme dire : « La couleur de ce chat est angora. ».
Pour résumer, oui un ordonnanceur qui implémente la politique SCHED_FIFO est un ordonnanceur préemptif.
Fait attention aux sites que tu lis. Certains expliquent des trucs qu’ils croient avoir compris, ça nous arrive à tous, mais quand on publie il faut être plus rigoureux de façon à ne pas induire quelqu’un en erreur.
Sur ton message précédent, j’ai été volontairement flou sur certains points pour pas te noyer au premier message. Si tu as besoin de précision, n’hésite pas à répondre là où tu as besoin.
[^] # Re: oups
Posté par Anthony Jaguenaud . En réponse au message commande nice. Évalué à 8.
Tu as deux modes de gestions multi tâches.
Le mode Temps Réél, et le mode temps partagé. Par défaut, on lance les processus en mode temps partagé. Je vais expliquer à la pelleteuse (très grosse louche) le principe de fonctionnement et comment nice modifie ça.
Quand on lance un programme en temps partagé, le noyau lui alloue un quota de temps. Partons du postulat que le quota par défaut est 100ms. Deux programmes « Ready » vont donc partagé le processeur chacun ayant 100ms de quota à tour de rôle.
nice
va modifier se quota : nice -m 20 va donner un quota de 120ms pour le programme correspondant. Mais n’empêchera pas l’autre programme d’utiliser son quota qui est toujours de 100ms. Néanmoins, sans nice chacun va s’exécuter pendant 5s. Si on a un quota 120/100, on va avoir un résultat de 4,xs contre 5,y (1-0,x == 0,y).Les processus en mode TR (temps réel) ne rendent jamais la main ! (enfin, sauf s’ils se mettent en attente avec
select
par exemple). En fonction des priorités, ça peut rendre un ordinateur de bureau inutilisable (interface graphique bloquée…)L’ordonnanceur choisi la tâche TR ayant la priorité la plus élevée, et l’exécute. Quand elle a fini, ou qu’elle se met en attente d’un événement extérieur, l’ordonnanceur donne la main à la nouvelle tâche prête ayant la priorité TR la plus élevée. S’il n’y a plus de tâche TR, les tâches en mode partagée sont exécutées.
La concurrence entre les tâches TR, s’effectue suivant deux modes. FIFO ou RR. Prenons deux tâches TR de même priorité :
J’espère avoir été clair.
[^] # Re: oups
Posté par Anthony Jaguenaud . En réponse au message commande nice. Évalué à 4.
Le sched RR (Round Robin) il donne du temps alternativement à tous les process ayant la même priorité. Ceux de priorité inférieur ne seront pas exécuté.
C’est Sched FIFO, qui attendra que la tâche soit terminé pour exécuter la suivante.
# Deux délimiteurs de chaine
Posté par Anthony Jaguenaud . En réponse au message Problème pour ajouter des guillemets à une variable. Évalué à 2.
En bash tu as deux limiteurs de chaine, en plus tu peux les coller pour les concaténer…
Après, ça peut dépendre de l’intérieur du script et de comment
sendmail.sh
gére le paramètre$1
[^] # Re: XMPP, ou pas
Posté par Anthony Jaguenaud . En réponse au message Utiliser XMPP pour un logiciel réseau. Évalué à 3.
Si tu es sur un réseau local, tu dois pouvoir trouver les autres avec du broadcast ou du multicast. Ensuite, avec la réponse tu as des IP, tu récupères les pairs des uns pour devenir pair avec les nouveaux.
Par contre, quid de la sécurité ensuite ?
[^] # Re: Bémol
Posté par Anthony Jaguenaud . En réponse au journal Optimisez votre code !. Évalué à 6.
Dans mon industrie, c’est l’inverse on court après les certitudes…
On a besoin d’être sûr que la boucle principale s’exécute bien en moins de 10ms (proc pas véloce) tout le temps.
Pour moi, l’optimisation doit être mesurable : gain, temps de dev et de maintenance… car la soupe infâme, quand il y a un bug, c’est encore plus infâme.
Au niveau de l’approche que j’adopte :
- Quelles sont mes contraintes temporelles ?
- Quels sont les traitements qui risque de déborder ?
En dév., j’essaye toujours d’avoir des algo en O(1). Quitte quand on a pas le choix, à chercher un élément dans une liste et quand on le trouve, on fini de parcourir quand même la liste.
Ma question pour l’auteur, c’est : entre le moment d’obtention des données et la limite de mise en ligne acceptable, tu as combien de temps pour combien de donnée ?
À partir de là, tu peux voir si tu tiens ou non. S’il faut optimiser ou pas. Parce que souvent, c’est rigolo d’optimiser, mais on oublie souvent que ça a un coût non négligeable. Dans certains métier comme le tien c’est vital, dans d’autre non. Par contre, si la maintenance à long terme est vitale, il vaut mieux pas faire trop d’optimisation (micro optimisation locale), et privilégier les bons algo structure de donnée.
[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . En réponse au message Udev m'en veut! :(. Évalué à 3.
Ok, donc
mkdir
retourne 1. Unman mkdir
sur mon linux RHEL6 ne donne rien d’utile, par contreman 2 mkdir
donne 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.txt
ensuite, 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 Anthony Jaguenaud . En réponse au message Udev m'en veut! :(. É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
mkdir
avec 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
if
suivant, ou si c’est un manque du log ?[^] # Re: Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . En réponse au message Udev m'en veut! :(. É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 Anthony Jaguenaud . En réponse au message Udev m'en veut! :(. É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 Anthony Jaguenaud . En réponse au message Udev m'en veut! :(. É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 ?
# Log après arrachement et avant rechangement ?
Posté par Anthony Jaguenaud . En réponse au message Udev m'en veut! :(. É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: On repart sur la guéguerre
Posté par Anthony Jaguenaud . En réponse au journal Pourquoi Emacs? (Première partie). Évalué à 3.
Il y a un journal : application qui se comporte comme vim car les vimeux doivent quitter vim pour faire certaines actions sur l’ordi en gardant leur interface alors que les emaceux restent sous emacs…
-->[]
Pour être sérieux, j’adore le mode modal de vim que aucune appli, pas même le viper-mode n’égale. Néanmoins, je trouve emacs plus cohérent avec son elisp.
Je suis encore en phase d’apprentissage d’emacs…
[^] # Re: spreadsheet
Posté par Anthony Jaguenaud . En réponse au journal Applications de type vim-like. Évalué à 4.
Je sais que le org-mode permet de faire des calculs dans les tableaux… Qu’est-ce qui te manques pour ton besoin qui fait que tu ne l’as pas retenu ?
# Recherche…
Posté par Anthony Jaguenaud . En réponse au message Firefox dans Fedora 27 et Netflix . Évalué à 4.
Salut,
Je viens d’utiliser le cadre « recherche » en haut à droite de la page. La requête : « Netflix » m’a renvoyé sur cette page dont le premier lien est ton post, et le second un post qui explique comment activé netflix et canalplay.
Bonne chance.
[^] # Re: Ca change !
Posté par Anthony Jaguenaud . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 7.
En fait, si tu regardes le premier lien de la dépêche, tu verras que c’est la traduction de cet article posté le 10 octobre 2017 soit il y a un peu plus d’un mois.
# Écrire…
Posté par Anthony Jaguenaud . En réponse au journal Le cauchemar d'Henry. Évalué à 8.
J’allumerai vite ma tablette pour me connecter à linuxfr histoire de demander un conseil hypothétique ;-) à des gens bien…
--->[]