Bonjour,
j'ai écrit 2 scripts :
- le premier réalise un : echo $1 >> /tmp/fichier_commun.log
- le deuxième réalise un : mv /tmp/fichier_commun.log > /tmp/fichier2.log
Les 2 scripts peuvent être exécutés en même temps par des applications différentes.(les utilisateurs peuvent différents aussi)
Je prétends qu'il ne peut y avoir de problème, mon collègue le contraire.
Pouvez-vous arbitrer ? svp
merci d'avance.
# flock
Posté par sputnick (site web personnel, Mastodon) . Évalué à 6. Dernière modification le 09 mars 2023 à 20:39.
Dans le doute, tu peux utiliser
flock
pour n'autoriser qu'une instance.(dans les 2 scripts, le même lock bien sur)
On ne peut pas mettre d'array dans le string...
# Tu as raison
Posté par cg . Évalué à 8.
Tu as raison, car le second script qui fait :
donnera seulement un message d'erreur de syntaxe sur la commande
mv
. Ainsi,/tmp/fichier_commun.log
sera préservé.[^] # Re: Tu as raison
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à -1.
C'est incorrect. Le mv n'aura aucun problème, même si quelqu'un écrit dedans au même moment.
Quand un programme a ouvert un fichier, il se fiche de savoir s'il est déplacé, même supprimé. Il ne retient que le file descriptor, qui n'est qu'un identifiant d'inode (pour faire simple) et peu importe si le fichier est déplacé ou supprimé.
Un gentil du net
[^] # Re: Tu as raison
Posté par Tonton Th (Mastodon) . Évalué à 4.
Là, le
mv
il dit qu'il a plus de genoux…Ce qui est valable quand les fichiers concernés (source+copie) sont sur le même filesystem, l'opération
mv
étant dans ce cas atomique.Par contre, si il y a changement de fs, j'ai quand même un doute sur le déroulement des opérations…
[^] # Re: Tu as raison
Posté par alberic89 🐧 . Évalué à 5.
Je me trompe peut-être, mais la syntaxe de la commande
mv
estmv source destination
. Donc, pas de>
entre les deux. Sinon, la commandemv
a un seul argument, et ta sortie standard est dupliqué dans ton deuxième fichier. Voulais-tu diremv /tmp/fichier_commun.log /tmp/fichier2.log
oucat /tmp/fichier_commun.log > /tmp/fichier2.log
?L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
[^] # Re: Tu as raison
Posté par cg . Évalué à 6. Dernière modification le 10 mars 2023 à 19:51.
Farpaitement ! Jusqu'au moment où tous les fd qui pointent vers l'emplacement sont fermés.
Petite démo rigolote :
On peut utiliser
lsof
pour voir le fd et l'inode :Bon au départ je voulais juste faire un peu d'humour avec mon commentaire débile hein :).
# Il peut y avoir un problème ...
Posté par totof2000 . Évalué à 4. Dernière modification le 09 mars 2023 à 21:21.
Veux-tu dire que script 1 peut être exécuté par plusieurs
utilisateurs en même temps, et script 2 aussi ?
Pour utilisation simultanée de une ou plusieurs instances de script1 et une instance de script2 il n'y a pas de problème.
Pour utilisation simultanée de plusieurs instances de script2 …. supposons :
- un utilisateur execute script 1
- deux utilisateurs executent script2, en déplaçant le fichier commun vers le fichier 2.
- entre temps un utilisateur exécute script1. L'enchainement donne, mais dans un temps très court :
* exécution de script2 (déplacement du fichier commun vers fichier2)
* exécution de script1 (regénération du fichier commun
* exécution de script2 (déplacement de fichier commun vers fichier 2)
Tu risques d'écraser fichier2. Il faut donc faire attention au nommage de fichier2 dans ton script. C'est surtout cette partie qui pourrait poser problème.
Maintenant tout dépend de ta façon de nommer script2.
[^] # Re: Il peut y avoir un problème ...
Posté par Krunch (site web personnel) . Évalué à 2. Dernière modification le 09 mars 2023 à 22:04.
Je vois deux autres problèmes potentiels.
Si le premier programme ouvre le fichier plusieurs fois, ses écritures peuvent être réparties dans plusieurs fichiers. Ça peut être le cas par exemple s'il s'agit d'un script shell qui a plusieurs lignes comme ceci :
Si le fichier est renommé entre les deux, les deux lignes seront dans des fichiers différents.
D'autre part, ce qui va lire fichier2.log devrait avoir un moyen de savoir si les écritures dans ce fichier sont terminées. Sinon on risque de se retrouver dans une situation ou on lit fichier2.log jusqu'à la fin alors qu'il n'est pas fini.
Selon le cas d'utilisation exact, ces deux situations peuvent poser problème ou non.
Une solution que j'aime bien est de tout donner à rotatelogs et de lui laisser gérer les fichiers : https://httpd.apache.org/docs/2.4/programs/rotatelogs.html
J'ai aussi écrit un patch pour ajouter un mode de tampon circulaire mais je sais pas s'il fonctionne toujours : https://bz.apache.org/bugzilla/show_bug.cgi?id=47170
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Il peut y avoir un problème ...
Posté par AQkinkin . Évalué à 1.
Bonjour,
il y a 2 applications.
l'app1 run script1
l'app2 run script2
il n'y aura qu'une app1 avec 1 user qui run script1.
mais il faut effectivement que je vérifier que l'app2 ne peux pas être lancé par 2 users.
merci beaucoup à tous pour votre participation.
[^] # Re: Il peut y avoir un problème ...
Posté par NeoX . Évalué à 4.
dans ton app qui ne doit etre lancée que par un seul utilisateur ajouter simplement laa detection de /var/lock/tonappli.lock ou /var/run/tonappli.pid
ces fichiers sont créés à l'ouverture de ton script/appli
s'ils existent c'est que l'appli tourne deja, et tu quittes
s'ils n'existent pas, alors tu executes l'appli
[^] # Re: Il peut y avoir un problème ...
Posté par totof2000 . Évalué à 3.
Toutes les applis ne gèrent pas ce lock. Mais effectivement si c'est fait, c'est une idée.
[^] # Re: Il peut y avoir un problème ...
Posté par NeoX . Évalué à 3.
vu que c'est appli semble lancer un script externe, c'est alors dans ce script qu'il faut gerer le lock ;p
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.